Progressive Web Apps Are The Future


Get the lowdown on Progressive Web Apps – why PWAs are the freshest way to reach more users and create richer user experiences and engagement.

Primarily, I’m an educator. So I manage the staff and the students for Denver’s Web Development Immersive Program. I also, before that, was the director of curriculum at a music school. And I taught all kinds of things before that. I was a ballroom dance teacher. I was a sharpshooting teacher. I taught rowing and canoeing. You just can’t stop me from teaching stuff.

I’m also a web app developer. So before Galvanize, I was a full stack dev on a skunk works team. And I also co-host the Sprint UX podcast, and I run the Denver Ember meetup.

And I’m panicking because this isn’t working. Hang on just a second. Bear with me, bear with me. We’re just getting to know each other.

And then, the last aspect is that I am a business dork. Now, as I imagine, a lot of you guys are probably business dorks as well. There we go. Specifically, I am in management, leadership, culture. That kind of thing. I have a Master in Engineering Management. I was a marketing manager for a pro audio firm for about four years. And I manage a team at Galvanize. All right, enough about me.

So what we’re going to talk about today is, by the end of this, you should be able to describe the relevance of progressive web apps, you should be able to describe what they are, and you should be able to talk about some of the technologies that we use to build progressive web apps. Off to the races.

Let’s start with a confession. I am crazy about native apps. I really don’t know what I like more though, the enormous downloads– and yes, that is 179 megabyte download for Facebook– or the high-friction first engagements that let users know that you’re worth it. Even better, you have an opportunity to inflict these kinds of things on your friends. Sharing content, which is maybe the single most-solved problem on the web, is a monstrous pain in the ass on native.

So let’s say, for example, you’re on Twitter and you want to share something that’s on Pinterest to a buddy. Think about the steps that you have to go through to do that. You go, hey, check this out. Someone goes, I would like to check that out. And then they get taken where? To an app store. And then they have to download a large– up to 179 megabyte– app. Wait for that– hopefully, they’re on Wi-Fi. And then, when they finally get that, what are they prompted to do? Create an account.

And they go, hey, I don’t want to have to manage another set of credentials, so how about I use my social login? So you click on a button. And then it takes you over to Facebook, and now you have to log in with Facebook. Once that’s done, you come back to Pinterest, and it goes, cool, now you got to give us a couple of permissions. So you give them some permissions. And then, after all of that, you don’t even get to your content. You have to go back to the Twitter link, and click on it again. That’s rough for engagement, is it not?

I also like everybody’s favorite meta engagement, keeping their software up-to-date. So you get an opportunity, really, to make sure that you’re on the most current version of everything that you have, lest you end up in that ransomware situation that everybody was in last week. And it really helps you instill a sense of tradition for the older states that your apps were in.

It’s really awesome as a developer too, because you get to maintain all kinds of different code bases. Not only your iOS apps and your Android apps, but if you have users with older handsets, like maybe an S3 or something like that, uh-oh. Now you have to maintain the Android versions and the iOS versions for the older stuff as well. And even if you’re not keeping up with feature parity, you still have to maintain security on all those things.

But I think some of the best surprises in this are really for managers, like forcing your team to make the important choices up front. Like do you try to hire and manage three different teams of platform specialists, and hope they can keep in sync on feature development? Or do you want to make it impossible to use your app for anywhere from half a billion to 3.5 billion potential users? So it’s a way of keeping you from getting distracted from having to serve too many people. So this pile of money on the screen, that can either be the money that you spend to maintain all of these teams, or it can be the money that you leave on the table by not being able to serve those users. Either way, it’s a pile of money. That’s worth something, right?

Speaking of piles of money, I like that we get to thank Google and Apple, not just with our words, but also with 30% of every sale that you make in one of their close stores. So you’ll note, too, that when in-app payments kind of exploded a couple of years ago, in-app payment revenue literally is double what download revenue is. But you have to build the entire in-app payment system yourself. So that’s not any different than you would have to do on the web. So you’re not even getting the supposed platform advantage of that. But by letting you build that payment system in, I think what Google and Apple are really trying to do is give us a sense of ownership of our hard work. It’s also teaching us patience.

It’s all presuming that you get into the app store at all, because they are good at keeping us humble. We can wait seven days for iOS, or if you’re in the OS X store, it might be as much as 27 days for approval. Steam does the same thing. You might be able to think of it as like a free QA team, and making us think long and hard about whether we want to push an update or really even deploy in the first place.

Luckily, it might not even be worth it. 60% of apps have never been downloaded by anybody. Half of U.S. users download zero native apps a month, and everybody all together averages about three apps a month. Furthermore, 94% of app revenue goes to 1% of app developers. So you get all of the fun of playing the lottery, America’s game.

Apps rule. Let’s talk about how we got here. How did this happen? So a brief history of applications. So native mobile apps have a prehistory. Contrary to popular belief, iOS and Android were not the first people to do mobile apps. We had this on Palm. We had this on RIM. We had some stuff before. It was usually small utilities. It was really with the introduction of iPhone and Android that this concept goes mainstream, right?

So a year later, they both release app stores. And the devs are off to the races, and Apple immediately declares themselves the winner because Android is fragmented and they aren’t. And then two years later, Steve Jobs lays down this brutal take down of Flash. It’s as brutal as a think piece entitled “Thoughts on Flash” can really be. But regardless, announcing that due to poor performance and battery life, and that open standards and the web are the way of the future, they’re going to stop supporting Flash.

So then a few years later, they release the motion co-processor. This makes it so that any time you want to use a gyroscope or any kind of device thing, your phone doesn’t explode when you try to do that. And then Apple fragments their own ecosystem by introducing a language that nobody asked for.

And then a year after that, deep linking starts becoming really popular. Deep linking is when you click on a link on a search, and it gives you that prompt, do you want to open this in the browser or this app or this app? And then you have to make the panic decision to do this, but ask me again next time, because I don’t want to be pinned into this choice. You ain’t going to get me on this one.

And then this year, the cool thing that we’re going to get is Instant Apps. This is a way to get a partial download of a native app without installing it, otherwise known as a web app. So let’s talk about web apps. They have a more interesting pre-history.

So in the early 2000s, Gmail comes out. And this is built off of a technology called XHR. XHR was a way to get content from another server, and then bring it back and then do something with it without reloading the entire page. And Gmail was, more than anything, really a proof of concept that you could simulate page loading without actually doing page loading. I think of that really as the first real web app.

And then at the same time that iPhone and Android were released, Googledocs came out. Now what was impressive about Googledocs is that this is the first time that I remember a mass migration to a web-based platform when there was an awesome desktop solution. Microsoft Office was everywhere. That’s what you had to use to get anything done. And then the second something with a tenth of the features came out on the web, everybody hopped ship.

So the following year, we get IE8. I think this might be the last time, since then, that everybody the world over has agreed uniformly that something was terrible. And we ended up having to live with IE8 for quite a bit.

So the web app community piggybacked on Steve Jobs’ war on Flash for a lot of the same reasons, honestly. Because in browser-based apps, you had to have a Flash plugin installed to play Flash content. Not everybody had it, so its the same kind of friction that you’re seeing with app stores now. And then, also, they had to keep all those plugins up-to-date. Remember you click on the thing, and then it says, hey, do you want to install our spyware also? And you go, you got me this time.

So a couple years later– it’s hard to understate the amount of coal that was shoveled into the hype-train engine that was HTML5. So, true story, I was working at Pearson at this time, and people would stop you in the hall and go, what are you working on? And you go, I’m working on a web app for this client. And they go, are you using HTML5? And there’s two things that they wanted to check with that. One was that you weren’t using it, because Facebook tried using it and they regretted it instantly. You can’t use HTML5. And other people wanted to make sure that we’re on the bleeding edge, that we’re using the latest technologies. If you scratch below the surface on that, nobody could actually define what HTML5 was, but they knew that you either definitely should or shouldn’t be using it.

Next year, something kind of interesting happens. Internet Explorer drops below 10% global usage. So at that point, it was mainly relegated to government agencies. Another true story from Pearson. I was working with a school, and they had a requirement contract of support for IE6, which is maybe the worst browser in history. And you go, why? Why can’t we just use a modern browser for this? And they said, you don’t understand. We’re in rural Tennessee. Our students are very poor. They can’t afford the latest browsers. Actually happened.

So the other cool thing that happened that year was asm.js came out. asm.js was a way to run C++ code natively in the browser. So around that time, you probably saw a lot of people reinstalling Firefox, or blowing the dust off of it, and playing first-person shooters in their browser. And it worked pretty darn well. And that ends up forming the basis for WASM, which we’ll talk about in a little bit.

So next year, HTML5 actually shows up. And this is an important inflection point in the history of web apps. Because HTML5 was really the dawn of the web as an application platform, first class citizen. Before that, it’s mainly documents. It’s just a way to show people information. HTML5 gave us Canvas, new styling things, all kinds of different APIs that we can use to make something behave more like an application and less like a document.

Next year, ES2015 comes out, also known as ES6 if you like being wrong about things. So ES2015, it added some kind of neat features, and some cool new syntax, but the really neat thing about ES2015 is this is the start of JavaScript as a rolling release language. So we had an ES3, and we had an ES5– don’t ask what happened to ES4– and then, we had ES2015. And then, we had a 16 and a 17, but people don’t really talk in those terms, because they aren’t big-bang releases anymore. There’s a process for features in JavaScript now, that, as soon as they’re ready, they ship. And that’s really important to where we’re going with web apps.

So then, ’16. I remember the framework wars as if they were yesterday, because they are still kind of happening. So as we’re getting this application-style performance, more and more stuff is moving from the server to the client, because the bottleneck in performance is waiting on that round-trip from the network. If the application’s running in the user’s browser, it doesn’t have to do the big round-trip. Ergo, runs faster.

So all kinds of frameworks popped up to support this. And people started using Angular, because it’s made by Google, so how could it be bad? Well, it’s actually pretty bad. And then they went, oh, I know the problem is that– I’ll just use React. It’s by Facebook. And then they looked at how you have to do state management in React, and went, Vue.js sounds cool. And then there’s people like me who lumbered over the mountain of corpses of people who tried to learn Ember.js and gave up. And then we all got to the top, and looked down, and were too scared to ever leave. So we’re never going to learn anything else.

I still see people go, well, I’ll learn a browser technology when they just slow down a little bit. It seems like there’s a .js for everything. You can play a drinking game, and you say a word and see if there’s a .js framework named after it. Now, here’s the truth. There are eight versions of Java. Standard and Enterprise editions, JSP, Swing, Ant, Maven. 28 active development run times, half of which are proprietary. Groovy, Scala, Closure JRuby, Jython– there’s a lot of this in any popular ecosystem. And I haven’t even named any libraries yet.

So that brings us to 2017, where famous luminaries the world over, like Eric Elliott, Jake Archibald, and this asshole, are telling you that progressive web apps are the future.

So this is an incredible article. I’d highly recommend everybody read this one front to back. It’s an oldie, but a goodie. “Apps have become nearly irrelevant on desktops because the web experience is close to perfect, while apps are vitally important on phones because the web experience is dismal.”

And he also talks about some things that happened around two years– remember when Microsoft was giving Windows away for free, and paying people to develop apps for it. It was trying to get everybody into their little proprietary ecosystem. And honestly, it didn’t work out that well, which I think everybody saw coming. But you were also seeing things like Facebook Instant, and all these ways to try to get around the fact that the browser experience on the desktop was so terrible.

He also points out that nobody is rushing to build desktop versions of their apps. Facebook isn’t trying to make a Windows app. Twitter isn’t trying to make an OS X client. Nobody’s knocking each other over to get there, because who cares? If it runs in the browser, you don’t have to install anything. It’s a better experience.

And even things that were stalwarts of the desktop, Microsoft Office, start going to the cloud. Things that could never be on the could, like Photoshop– well, guess what? Photoshop Streaming has been in dev for a while now, a way to run Photoshop in a browser. And even things like– oh well, definitely not games. You can’t do games. Games are kind of going a different direction. Valve is trying to make PC gaming more console-like by having closed ecosystems that don’t also have a whole bunch of other things.

So that’s leaving audio and video editing, which Apple has functionally abandoned– and I remind you, I come from that industry. So everybody else in there is a dinosaur waiting to be disrupted. That’s what you guys do here, right? Go disrupt that. And then things like iTunes, which is an absolute horror show next to SoundCloud, Spotify, Google music, or any modern music experience.

So nobody likes native apps. If given sufficient opportunity, they will go to something else. The mobile web experience really just has been that bad, especially on iOS. So then your boss says, I don’t care. Get them in however you have to, bring them into the website, but make sure they install the app. They have to install the app. Be as obnoxious as you have to be. Please make sure they install the app.

And so it’s probably based on some statistics, like 80% of an average user’s time is spent in apps. And you go, yes, but 80% of that time is in three apps. The average user installs zero apps per month, as we said, and the average user visits 100 sites per month. If you are a startup, if you are looking to get user attention, I would rather play this game than this game.

I was reading an article, right before this started, with some people talking smack on PWAs. And one of the things that they all brought up is that when somebody asked them to install their app, they had to figure out whether or not they’re sponge-worthy. Is this really a thing that I want to do? You don’t make that same determination on, do I want to go to that website? Because it is such a painless experience.

They say, well, you know those native app users– we’re a business. We’ve got to get some of that nice, native app user revenue, especially those iPhone users. Cash cow, cash cow. They go, yes, but there’s three marketing concepts you have to keep in mind here. Reach, how many people can you access? And then of those people, how many can you acquire? And so in our case, that’s installing the app. And then of those, how many can you convert?

So mobile web’s reach is two and 1/2 times bigger than native’s. Their acquisition costs are 10 times cheaper, because all that money you pay to get people to download and install your app, all the friction in all of those steps means that they abandon it. Ergo, it costs so much more to get them to actually convert. Conversion rate is much higher once they get there, also, because of all that removal of friction.

And they say, well, performance is king though. Why would somebody use the web? It’s not as performant as a native app is. 40% of users bounce in three seconds. I can’t play those kinds of odds. Yes, but every click in the install process loses 20% of your users. Every single one. And Google did a famous study on interstitials. This is why you don’t see so much anymore the modal, take-over-your screen, install our app or else. And the reason is that they did this study. 9% of people clicked on the thing and installed the app, and who knows what happened after that. A full 69% of users not only didn’t install the app, but didn’t go onto the desktop version. They abandoned it all together. So you’re not even getting a chance to play the performance game.

So let’s take a look at the current landscape of native app, web app, and hybrids. A hybrid’s a special kind of app category. So this is, essentially, a web app that runs in some native app clothes. Examples of this are Cordova, PhoneGap, Ionic, these are hybrid web and native app.

So first use. This is, hey, check out my content. First use on native is terrible. Always has been, always will be, because of all of those gates that you have to jump through to get there. However, second, third, fourth experience? Amazing. Fast, responsive, instant load. On the web app, they’re just kind of OK in both cases. The Bible that web app developers go by? One-second load time. We’ve been able to pull that off, and it’s even as we develop new technologies. We have to live inside of the constraints of the one-second load time. So you’re still getting something that isn’t bad, it’s just not any better on subsequent loads. And then the hybrid app, it depends on whether they went to your web app, or went through that native install process, how good their first use is. But they have all the same benefits on nth use as native apps do.

Offline. Native apps can do it, browsers can’t. Hybrid apps are the whole point. You get all of these benefits.

Access to sensors, camera, gyroscopes, that kind of thing. You’ve got it on native, don’t have it on web apps, have it on hybrid.

Performance. It’s awesome on native, terrible on web apps. It’s all anybody talks about. Hybrids? Debatable. People will say that you just gotta live and die by that performance, and how can something running in a wrapper match the performance of native? Slack is a hybrid app. Slack is awesome. That’s the fastest company to ever reach a billion valuation. So tell you what, get your billion valuation, and then let’s talk about how bad the performance on hybrid apps is. The reality is that having a hybrid app doesn’t mean you can suck at app development. There’s a lot of jank, there’s a lot of crap, there’s a lot of poorly made apps in the hybrid space. Same here. Same here. Dollars to donuts, you can make a good performant hybrid app.

Dev cost. It’s super high on native, because you need platform specialists. There are fewer of them, and that drives up the cost. Web apps are cheap as hell to develop because there’s guys like me just cranking them out. By the way, if you would like to hire a web app developer, I have people looking for work. But ubiquitous, right? There’s a low barrier to entry. Hybrid? Medium. You get a lot of the benefits of hiring web app developers, but you still need to tailor to the platform a little bit. You still incur some of that expense.

Device agnostic. Absolutely not. The whole point of this is that it’s per platform, right? Web app, nope. If it runs a browser, it can run your app. Hybrid, same benefit.

So sharing. It sucks on native, is perfect on the web, and can suck on hybrid for the same reason as the install process. It does not hit a wide audience. It hits a niche audience. It hits a wide audience. It hits a wide audience. So that’s where we’re at right now.

Let’s take a look at how browsers have changed. There’s a couple things I want to just show you about this. This is the, can I use charts for browser capabilities. In 2007, what kinds of things can the browser do? This green area over here is things that every browser can do. This little block right here is things that everybody can do, some of them do a little bit different, but all of them can get it done. This is things that some browsers can do, some browsers can’t. This is things that no browser can do.

So we jump forward to 2015. There’s way more density over here. This is a lot longer. We’re still seeing a lot of action, a lot more stuff filled in here, and not so much stuff here. In the last two years alone, look how much denser this looks now, how much longer, how much more filled out this is. And we’re experimenting with all kinds of wacky stuff, but there’s very few things– almost exactly the same as here– that no browser uniformly supports.

For example, specifically, did you know that your browser can do offline? It does it just fine. It can do push notifications. It can access the camera, the microphone, that kind of stuff. It can do virtual reality. It can work whether or not you even have the browser open. It can talk to other web apps. You can see the user’s battery life, and either serve up different content or give them options based on that. You can access vibration on mobile devices. You can see the connection quality, and either serve up low resolution images or prompt them with options for that. And you can synchronize stuff in the background. So when they get to your app, the content is already loaded. You want to talk about performance? How about not having to make the network request at the time that you want it? It’s already there.

So why the web? Why not another universal platform? Why not Java, or Flash, but smarter? Or why not hybrid apps, for that matter? Who knows what this is? Anybody? Babbage. It’s the difference engine. This was the first app. This thing calculates polynomial functions. So if I have this, I can do that. If I want to use that, I have to either transport it somewhere, or build my own, right? So this is our original app.

Then we got to floppy disks, then CDs, then downloads, and then app stores. So after this, everything starts getting platform specific. Transporting the software around becomes really easy, if you have the thing that runs it, which some people have this, some people have this, some people have this. App stores take some of the friction out of the install process. They really manage it in the background, but none of that has really moved, at all. So the web is what gets us the, hey, I want this thing and now I have it. I don’t have to take other steps. I don’t have to own the right things. The problem in software has always been distribution.

Because of money. So here’s some stats for you. Half of the web’s traffic is already coming from mobile. You’re not actually selling anybody on the idea of using the mobile web, they’re already doing it. You’re just trying to make it suck a little bit less.

So we said earlier that in-app purchases are worth almost double. In-app purchases generate $37 billion a year. Paid downloads generate $29 billion a year. And we’re talking no gatekeepers. You don’t have to get rejected from the app store, or wait a month. You just do it. And you’re building the tooling anyway. You have to with in-app purchases.

And we talked about the lower acquisition costs with the [INAUDIBLE] because of the lower friction. And because hybrids are a half solution. They take on the benefits of native, but they also keep their downsides. You’re still developing for a specific platform. You still have all that install friction. You’re still cutting Google and Apple into the sale. And you’re still doing this translation layer, which, even if you can minimize the performance cost, is unnecessary.

Enter the Progressive Web App. So progressive web app is largely just a marketing term for a very broad set of philosophies that you can use to build web applications. It’s not a framework. It’s not a library. It’s not any tools you’re using other than what’s in the browser. Thinking of it more as a checklist is a little bit closer, but I think it misses the forest for the trees a little bit on that. You want to think of this as an approach to developing applications in the browser. More plainly, a progressive web app is something that is reliable, fast, and engaging.

There’s a couple of cool things I think they did with this logo. These are all different devices, and some of them have things like front-facing cameras, and flashes, and that kind of stuff, and some of them don’t. And that’s getting more to the spirit of how we want to think of our apps.

So some concepts in progressive web apps. First is the progressive part, progressive enhancement. I like thinking of things in terms of what they are not. What is the opposite of this? So progressive enhancement is the opposite of gradual degradation.

It used to be that you make the Cadillac app. This is the monster. This is the one that we like. And then, as we try to widen the tent and invite more people in, we can take this feature out, we can take this feature out, we can take this feature out. The problem is it doesn’t work all that well.

Progressive enhancement takes it from the other direction. It’s like, OK, if a user only has a screen this big, no camera, no gyroscope, what can we do? What can we give them? And then, as they get these things, what else? What else? What else? The benefit is as new APIs, and device features, and all that kind of stuff become available, we’re able to tap into those because we’re able to progressively enhance the experience.

They are responsive. So I remember having an insane conversation with a company that was doing iOS development once. And I said, yeah, why don’t you make this a web app? Even at the time, this was 2009 maybe. And they said, well, we just can’t deal with all the fragmentation in the Android system, so many screen sizes.

And this is not an axis that web app developers generally think on. You think in terms of like, OK, if I have this much real estate, I want to use it this way. And as it gets smaller, I want it to do this, until it hits this target, and then it adapts. So we have a very robust set of tools for handling this kind of styling strategy at this point. It’s not like laying out something, and it’s 400 pixels this way and 800 this way. Responsive design takes into account that you could be doing something this big, or jumbo-tron.

They are independent of your internet connection. That doesn’t mean that the experience is identical, but on an app, if you don’t have internet, you can still load up the app. And it might say, hey, buddy you’re not online, or the content might be slow to load or whatever, but you still have the navigation, you still have the general shell of the application available. And since we have all those cool APIs that tell us whether or not we’re online, we even have one that tells the quality of the connection. We can either display that to the user, or give them options, or make intelligent choices on their behalf.

App-like. Specifically, what app-like means in this context is just that. The structure of the application and the content are separate. You want the content to come in over the network– more on that in a bit– but the general structure of the application itself should be something that is cast, ready-to-go, just like an application is.

Fresh. This is solving our bunch of different versions issue. Everybody should always be using the current version of the application. Since one of the ways that browsers do all of this is intercepting network traffic, and then doing something with it, that’s a ripe opportunity for man-in-the-middle attacks. Ergo, for this to be viable, it has to be secure. You also get the added benefit of encrypted traffic and protecting your users, but this is table stakes in progress web apps.

Discoverable. People go, oh, but how will people find my app? Well, there’s this really popular company that makes it easy to find things on the web. And one of the ways that they’ll know that you have an application, and not a site, is that you have declared it as such. And we’ll talk about those technologies in a bit.

And progressive web apps are re-engageable. So you’re able to do things like push notifications, OS level notifications, and all the things that you already do to re-engage users.

They are also installable. So we’ve talked about that install friction. What if the friction didn’t exist? What if you’re using the application, and if you want to make it easier to get to in the future, you just click a button? You know, like bookmarking. So you can do that, but in an app style that will show up on the home screen of your phone, and then will come up again with a splash screen, and not have the URL bar and all that kind of stuff.

And lastly, the greatest feature of the web is that content is linkable. You want to share something with somebody? Send them the link. No install necessary.

So this is getting a lot more common. I made these last night. This is Uber. This is Twitter. This is Facebook. Recently, I’ve seen– especially like in the last month or so– this PWA thing is starting to get some steam. There are things that you would think you could never do that on a desktop. How? Why? But they need to know where you are. Like this is Pier 36, right there. That’s my hotel. That’s an actual thing that you can do.

And then, I’ve got an interesting story about the Facebook one. So the other day, I went to uninstall Facebook because I don’t really use it that much. I was starting to get the notifications, and I don’t– this is a bit much for right now. And it turns out, I had never installed it in the first place. It’s a PWA, so I was getting the exact same experience that I did when I had it installed without having to do any of those steps.

So here’s a couple of case studies. The Weather Channel does a PWA, and within three months, one million users opt in to receive web push notifications, 52% of those coming from mobile. And, going back to our reach thing, in 178 countries. And they also got an 80% improvement in load time from their old web app.

Washington Post. It’s probably the most well-known case study. So they got a 23% increase in mobile search users who returned within seven days, and an 88% improvement in their load time for their content versus traditional mobile app.

So let’s talk a little bit about how we build these. If you are not a dev type, bear with me. It’s going to get a little bit nerdy, but I promise you we’re going to bring it all right back. So the cornerstone technology in progressive web apps is Service Worker. So you can think of this as a programmable proxy. I go, yo, I want some content. And then, rather than going directly to my back end, or an API, or whatever, Service Worker gets a chance to intervene.

And so Service Worker can say, yo dog, you’re online right now so I’m going to let you do that. Or, no dog, you’re not online right now. I have some of that cached though, so I can give you that content. And you can actually build some strategies around this. You can say, I would prefer it be this, but if you have this, let’s do that. Or give me this immediately, and as this becomes available, give me that instead. Or no man, this is stock prices or something. I only want what’s happening here. So you can go network only, cache only, cache then network, network then cache. Or my favorite one, you can make them race, and see what comes back first and go with that.

So this is really what’s powering the offline experience in progressive web apps. But that’s not all. This is the other cool thing. Service Worker runs completely separately from your app. This is what allows it to work whether or not the browser is open in the first place. It’s what enables push notifications. It’s what enables web apps to talk to each other. It runs on a different thread. It’s its own process. As long as the browser process is running, the windows don’t have to be open. You don’t have to have the browser window open, any of that kind of stuff.

So the next big technology is cache and IndexedDB. So they perform a very similar task for very different kinds of things. Cache is what’s storing the current version of your apps. So you go, all right, this is version 38 of my app, use these assets. This is the shell of my application. And then when you come up with a new version, you discard the old one, and bring in the new one. And so that’s what’s coming up every time you’re offline or something, that instant load. That’s coming from cache.

IndexedDB is a database in your browser. If any of you are familiar with NoSQL, it’s a NoSQL database that runs just in your browser. So this is for dynamic data. So you can go, hey, I want user 3 or something like that. And then you are able to get that user from cache. You’re essentially recording requests to networks and their responses. So the next time that request comes in, you have the option to retrieve that from cache instead. You can also do some kind of neat things with this like selectively add something to IndexedDB. Let’s say a user wants to save an article for later, or something like that. You can power offline experiences that way also.

So I think we’ve used the term push notification here before. Those are technically two different things. So, this is a notification. It happens at the operating system level. And on some operating systems, you actually get options you can do here, like maybe a question, and you click yes or no, or have the opportunity to fill in a response or something if you want. You have a programmatic way to do something with that information.

The push API, this one is kind of interesting technically, how they pull it off. This is, app isn’t open, but what I did is I registered this user, and they get a URL that your back-end can make a restful request to, and at the OS level, it will figure out how they want to display that to the user. So that might be, no, they’re on do not disturb right now, as soon as they’re out, I’ll give them that information. Or the same way you do on mobile phones, or do messages, any that kind of stuff. This is different than sockets, by the way. There are some devs get confused about this. In sockets, the app has to be open, and then you have real time communication. This is asynchronous communication, but otherwise, kind of a similar idea.

Manifests. So this is the tool that you’re using to identify your website as an app. And you can tell when people are doing this, because they’ll theme the URL bar if you’re on the web. It also will enable you to do things like add them to your desktop, and say no, and I don’t want to have this kind of splash screen, and these are the icons that I use, at this size and this size and this size. That’s manifests. Manifest is the standard. There’s also ways to do that with meta tags on other browsers.

And if you’re searching online, and you see this logo, it means you are about to get a fast experience. However, as a developer, you need to be very cautious about this. This is probably the most controversial of all the things that I’m showing, because from the dev side, you make some trade-offs in doing this. But the experience for users is an average of one second load time runs four times faster in the user’s browser, and uses 10 times less data. It does that by using a very strict subset of HTML, a strict subset of JavaScript, and Google caches all of their responses. There’s some more to that though. So if you’re curious about doing this, read up on this first.

And then, there’s so many cool APIs in Navigator, like seeing the user’s battery, their network connection, where they are, how many processor cores they have. So you can say, JavaScript is single threaded. Well, you can actually spawn new threads with web worker, and you can see how many cores the user’s computer has, and make choices based off of that. You see whether they’ve got VR devices attached, you can make the phone vibrate, camera and microphone, all kinds of cool stuff.

Restyling. Web styling has come an awful long way in the last 10 years, the last two in particular. So we have a flex boxing grid, which enables you to do all this cool responsive layout stuff. And there’s a picture tag now. This allows us to say, well, if the device width is this, deliver this image. True story. Images, by an order of magnitude, , are the biggest data hog on the internet. You crack that problem for your users, now we’re starting to get to that nice, fast, performant experience. And you have two different tools. Media queries for, the browser is this big, ergo, I want to do this thing. And you also have match media, which will say, it’s on this kind of device, it’s a mobile device, make the headline shorter. It’s new art direction kinds of things. Or I’m on a desktop, so give me the whole headline in all of its glory. And then we can also support very modern jank-free animations. And that’s our styling options.

Coming soon. Oh man, we’ve got some cool stuff coming down the pike. So, service-side hydration. This is a performance thing that native apps couldn’t dream of matching. So with this you say, hey, I want this resource , and it’s an application, so the application needs to come down. But you have the option of rendering the whole thing out as just normal HTML, bringing that down as quickly as possible, and then in the background, the application pieces become available over time. Wow!

You have a standardized Payments API. So rather than having to implement all this crap yourself, you go, yo user, I would like some money. And they go, cool, I would like to give you that money. Touch. Done.

We have web credentials API. It’s the same thing with creating accounts, and logging in. The same way with your authenticating into your device, you’ll be able to use that to create accounts and log into services.

I told you about asm.js earlier. This is our play first-person shooters in the browser? So more generalized, this technology is called WASM, a WebAssembly. This is something lower than JavaScript that you can write to. So if you hate JavaScript for whatever reason, and nobody hates JavaScript, but if you do, or there’s a more appropriate language for your task, you can write your apps in C++ or Python or Ruby, or whatever you kids these days are using.

WebGL. So WebGL has been around a little bit, but oh boy, is it about to get a lot cooler. This is a 3D rendering in the browser that doesn’t rely on any plugins. And you’ll be able to capture user generated media, and stream it over standardized API.

So here’s an asterisk on everything that I just said. We’ve got to talk about this situation a little bit. This is a long one, but I think it’s worth doing in its entirety.

“We know from painful experience that letting a third party layer software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to developers.”

Oh, it tastes so good. So this was in that “Thoughts on Flash” thing on why Apple was moving away from Flash. However, they find themselves in a precarious position now, because– bomb coming in three, two, one. So, bear with me a sec, I’m prepared to defend it. But there are some serious issues with Safari relative to all the other browser vendors.

So this is the state of Service Worker right now. I know you can’t see what these say, but it doesn’t matter. These are all the technologies that are necessary for a Service Worker experience. All this gray on the right is Edge and Safari. Now Edge doesn’t have this either, don’t get me wrong. However, Edge is actively working on this. And the scariest thing on there is this little yellow box up here. This says, are they interested in putting Service Worker in their browser? And it’s a yellow because this is the last we heard from Apple on Service Worker. Two years ago, they said, we should do that. Are they are, in fact, doing it? Who knows.

And we have some reason to be concerned, too. Because part of the Apple rules are that, on iOS, every third party browser has to use the WebKit engine. Conveniently enough, Safari doesn’t. And up until about five months ago, Apple made everybody else use a very crappy version of the engine, while they used a much better one. Now everybody can use the better one now, as of December. But they still can’t bring their own engine. If your browser has support for Service Worker, or credentials API or whatever, you can’t bring that experience to Safari. You also can’t change the default browser. So if you’re in an app, or in some kind of result you’re getting outside of a browser, and you click on the link, it will always open in Safari.

And there’s a lot of little one-off issues. This is the most IE-like behavior of this. They have a different way of doing manifests than everybody else. They were super slow– by super slow, I mean five years slow– to adopt IndexedDB. They stuck with an older standard that they put effort into called Web SQL that everybody else abandoned five years ago. They were still driving that one home. And so this leads to a very familiar pattern to old timey web developers of, if this browser, do this. Otherwise, do this for everybody else. They have their own payment API.

Oh man, and weird media rules. This actually happened to me. I was presenting an app at Adobe MAX a couple of years ago. It was a new platform that had video content, and as the content went on, the URL updated. So you could do things like bookmark your favorite part, or send somebody else the URL. It was awesome. The problem is that I developed it– I tested it on Windows, on Linux, on OS X, and on Android phones. I get there, and they give me an iPad. And I go, hey, no problem. How different could it be? It’s a browser app. And what happened was you cannot change a URL and play media without the user taking an action. I thought, OK, cool, no problem. Well, I’ll just tick that box in the browser. And they go, oh no, we don’t have that. I go, OK, cool, I’ll get the user’s consent. And they go, oh no, it’s not an option. And I was like, I don’t know, how do you hack around this crap? And I found three or four hacks that people had done that had been instantly patched by Apple. Not allowed.

Not an evergreen browser. So you have to do it on their release cycle, and they’re currently releasing every year, year and a half. Ouch. And just like the issue with Service Worker, they have not publicly stated any interest or support for WASM. So it takes a little bit of time to develop this, that’s not a problem. But without that interest and support, people don’t know if they want to dump the resources into betting the farm on these technologies. That is hurting the web, as a platform.

Even still, here’s some truth about iOS. One of our core beliefs in progressive web apps is that the lack of availability of a feature does not break the app experience. So if you don’t have Service Worker, yeah, you miss out on some pretty cool stuff. However, it’s still a good mobile experience. For example, Ali Express– this is the Alibaba marketplace– their progressive web app had two times more page views, a 74% increase in time on site, and 82% higher conversions on iOS versus their native app. So even doing these things, you still get the benefits of PWAs, even if you don’t have all of the features. And there’s a lot of the parts of progressive web apps, like that app/shell pattern and caching, that don’t depend on Service Worker. You’ve got all kinds of ways you can do that without that. Really, what you’re looking for is just to not suck.

So the other ROI aspect of this is, let’s say you go, well, we can afford to piss off these luxurious iOS users. So we’ve still got to make a native app. Well, you could do a hybrid of your existing web app, for one. But if that’s not going to cut it, you go, well, we’re going to spin up a team for that. Well, you have a web team now, you have an iOS team, but you don’t also have an Android team. So that’s saving a third of your development cost, right off the bat.

So some things that you can do to get started with progressive web apps. So there’s some low hanging fruit. First thing is move to HTTPS. If you’re not on it already, do that. You can go to Let’s Encrypt and get a certificate for free, if you need to. Add a manifest. This is something you can do in minutes. This will identify your application as an app, and improve the experience, allow add to home, all that kind of stuff. And the next thing would be start using some of these caching strategies. So whether that’s network, or whether that’s app/shell kind of stuff. And then the next thing you can do is, start taking things that you have on the server, and push them into the client. You can still do app/shell style stuff, and client-side render the middle of it.

An overall migration strategy for existing apps. Well, you can go ground up. You can say, all right, we’re going to build a new progressive web app from the ground up. You can go with a simplified version. So this is, well, it doesn’t have all the features. It goes alongside of our existing app. Or you can go single-feature. Air Berlin did a progressive web app. And the thing that was the most crucial to them– to have this awesome experience– are the boarding pass. Right? You go there, you need that. Airport Wi-Fi is terrible. So is the connectivity. I live out in Denver. Airport is out in the middle of nowhere, man. So they were able to get a lot higher user engagement just by adding that feature as a PWA.

So if you want to learn more about this, you’ve got some options. Google’s PWA site is killer. And they also have a free video course that you can use.

And then, all of the other technology we’ve talked about, remember, this isn’t a framework. This isn’t a vendor thing that you’re buying into, this is just regular old stuff that’s available in browsers now. So hit up MDN for the APIs on all of these. It doesn’t even need to be a full PWA effort to take advantage of any of this stuff.

Google also makes a cool tool called Lighthouse. So this is either a command line tool, or a browser extension that you can use to essentially do an audit of a site. So this is Facebook’s PWA. 68 out of 100? Good, not great. But it will tell you point by point all the things that you need to do to hit all those punch list items that we were talking about earlier.

If you’re a developer, also, there are some really nice tools for doing some best practices. For example, that caching strategies thing– network first, cache first, race– a lot of that stuff is baked in as Easy Bake API that you can use with sw-precache and sw-toolbox. Those are node modules, by the way. And then analytics are kind of an interesting case, right? Because with a web app, you want to find out what the user is doing, but they do that by kind of sneaky sending messages. Well, if you’re offline? So there’s a node module for it that will store up all of those and tell you everything that your users did as soon as they get back online.

So our objectives on this were to find the relevance of progressive web apps, to find out what they are, and we wanted to understand their underlying technologies a little bit better. So why? Because native apps were never that great to begin with, hybrids are a half solution, and the web is the ultimate platform. What are they? They are progressive, responsive, offline-able, app-like, fresh, safe, discoverable, re-engageable, Installable, and linkable. How do we make them? We make them with Service Worker, with cache, IndexedDB, notifications, push, manifests, Navigator API, Flexbox and Grid, and Web Workers.

So let’s take a look at that chart one last time. So if we add PWAs to this, first time use? Killer. We’ve got server side hydration, we have AMP, we have all kinds of ways to make the first experience awesome. Every subsequent experience? Also, pretty killer. Offline? You betcha. Access to sensors? Uh-huh, through the Navigator APIs. Performance? Outstanding. Dev cost? Super low, because we’re using web technologies. Device agnostic? You betcha. Sharable? Wide audience? Check, check, check, check and check.

So that is why progressive web apps rule, and progressive web apps are the future. Thank you very much. My name’s Kyle Coberly.


Level Up