PWA app: Are they the future of the Internet?

To steal from Alex Russell, it’s just a website that took all the right vitamins. It starts life in a browser tab like any other site, but can progressively become an app.

A bit more specifically, if it meets the technical requirements and a user visits the app again, they’ll be prompted by the browser if they want to add it to their home screen. From that point on, when a user opens the app from the home screen it receives the same visual treatment by the Operating System as if it were a fully native app. Meaning it has a home screen icon, shows a splash screen when opening, runs from cache first, etc.

You should also read Alex’s post in which he coins the phrase.

1. We now have a way to write an app that’s treated as a first-class citizen by an operating system with over a billion active users.
2. The tech required to do this is either supported, or being built by every browser vendor other than Safari.
3. The web can now be made to be completely reliable. And network connection is optional. With ServiceWorker the web can now implement the same cacheing strategies previously reserved for native apps. Some people really focus on the “offline-first” thing. But it’s not about being fully functional without a network connection – it’s about knowing that when you tap my app icon, it will open immediately, every time, regardless of network conditions.
4. Native push notifications.

1. Application manifest
2. Service Worker
3. HTTPS… yup. Gotta do it or this stuff won’t work 🙂

1. Awareness. There’s nothing in the way at this point. I think we’re going to see them popping up all over the place in the latter half of this year.
2. Confusion. These things are hard to talk about: is it an app? Is it a web app? Do users like them?
3. It’s early but I think we’re going to see an absolute explosion of them this year and next.

I can’t talk specifics about my current client. But I can say that the biggest challenge is the mind-shift required by developers and product alike. A lot of product leads don’t know they want one yet or what it can mean for them.

Also, PWAs put the web solidly in the realm of the “app” in terms of architecture. Frankly, most web developers are not used to building apps as fully self-contained client side applications. This will take a bit of time.

Ultimately, the reason I’m so bullish about this tech is because of how dramatically it seems to improve on-boarding and decrease cost of customer acquisition.

Rather than showing spammy app banners and “please install our app” door slams, it just asks the users at a point when they’re likely to want it and the “install” is non-existent because they’re already using the app! There’s no, “please install”. Instead of shipping them off to an app store and hoping they’ll install your 40mb app and log back in there, you’ve already got ‘em. This is why I think businesses will flock to this tech once we see more data about business impact.

ServiceWorker is a separate JavaScript file that your web app can “register.” Once registered it acts as a proxy. All requests your app makes from that point on (even to external domains) go through that ServiceWorker proxy first! From that script you can control caches and choose whether to answer from cache or network or both, or whatever else you can dream up.

In addition, ServiceWorker runs in the background, which means you can do interesting things like send it a push notification that will be shown to the user even when the browser is closed!

Other interesting features are being added via ServiceWorker too. One such example is background sync where your service worker can keep trying a request in the background until it resolves. Which means actions queued up while fully offline could be re-tried and completed long after your app and the browser has been closed.

In the future this script can be extended to do things like background geolocation tracking, etc. Imagine being able to build an app like “Runkeeper” entirely with web tech.

There’s a new ”CacheStorage“ API (which is also available as ”window.caches“ outside the worker). This is a Promise-based API optimized for storing/retrieving Request and Response objects and matching them to their related URLs.

The story here is still evolving. But it’s very much like any Single Page App at this point. If you want your content indexed it’s probably best to pre-render as much of it on the server as possible. That said, GoogleBot is pretty great at running JS. But in reality, most people building these types of experiences are building things for logged in users with personalized content anyway.

All this said, I would not be in the least bit surprised if at some point PWAs get preferential treatment by Google’s search algorithms. I hope this happens because in my opinion, this would all but ensure wide adoption.

The “offline” word is a distraction, in my opinion. Frankly, so is the word “progressive.” This is about building completely reliable experiences with web tech and teaching users they can rely on web apps for things they normally think they’d want native apps for.

1. Life will be easier if you build your PWA as a set of completely static assets. It makes it easier to know what you should cache, etc.
2. Try writing a ServiceWorker from scratch to get your head around it, but then check out all the goodies in: https://github.com/ GoogleChrome/sw-toolbox.
3. Right now all IoT stuff has a related native app. This simply will not scale when there are hundreds of connected devices you want to interact with. The web will win here, eventually, and PWAs are the logical way to interact with a world full of connected devices.

I use Twitter as a professional tool and tweet almost exclusively about tech stuff. So connect with me there: @HenrikJoreteg. Since going independent last year, I’ve brought my blog back to life and will post my best thoughts there.

If you’re interested in my professional help, you can get in touch about consulting.

This article is now available as a free PDF. Subscribe to Hacker Bits and get it FREE.

Interview was edited for brevity and clarity.