A Gentle and Practical Introduction to Progressive Web Apps

Progressive Web Apps (PWAs) are growing in popularity and are growing in importance for web developers. Let's—gently—dive into the basics.

Progressive Web Apps

Progressive Web Apps (PWAs) have increasingly become an important topic for web developers. If you've ever spent any time looking into the subject, it can be… a bit overwhelming. What I hope to do in this article, and the ones that follow, is gently, and slowly, introduce you to the basics of PWAs, what they mean to me, and give you practical advice on how you can start building PWAs today. In the final installment, I'll share a simple but complete PWA that you can use as a starting off point for your own applications. I'll also share plenty of resources along the way that can help you learn more.

PWAs are new to me as well, so please let me know in the comments if you think I've made a mistake, or perhaps when you simply have an alternative take on the subject matter. Remember that the end goal of all of this discussion is a "Better Web" for your users. A theme you will see me repeat throughout this series is to take baby steps. You don't need to convert your site over to a "complete PWA" overnight. Every small step you make in improving your app is a good thing. Never forget that!

What is a Progressive Web App, Exactly?

Let's break it down. When we say a web app is "progressive", we are saying that we are using an application that is progressively better for more modern web browsers but still works perfectly fine for older browsers. Ok, so what's a real example of that? Imagine you're building an application that browses product data. In order to improve performance, you could cache a lot of data about the products in the browser. How? By using IndexedDB, a browser native NoSQL solution. This is a great feature that will improve performance in browsers that support it. But for browsers that can't use IndexedDB, they can still browse product data by making requests to the server. When, and if, that particular browser is updated to a newer version and it supports IndexedDB, then they begin to gain the benefits you built into the site. But the crucial part is that the older browser is not blocked, or prevented, from using the site.

Hopefully I don't have to explain "web" - spoiler - you're on the web right now.

The final part, "app", is a bone of contention for me. I think there's room for disagreement over what constitutes a web "app" versus a simple content site. A blog, for sure, isn't really an app. GMail is undoubtedly an app. Your bank, however, may be a combination of both. It could have a large set of 'simple' pages regarding mortgages, accounts, and other terribly exciting stuff while also having a more traditional "app" view for managing your account.

However - every site can benefit from the features of a PWA. So don't go into learning PWAs as thinking you must be building a SPA (single page application) or something else fancy. Even "simple" sites will benefit from turning into a PWA.

More Details, Please!

Ok, but what is it, really? In some regards, you can think of PWA like any old marketing term. That may sound dismissive, but if you remember for a while, "Web 2.0" was used in a similar way. All "Web 2.0" really entailed was using Ajax to dynamically refresh content on a web page. (You could also include things like user generated content as well, but you get the idea.) The term "Progressive Web App" was first coined by Frances Berriman and Alex Russell way back in 2015. Initial discussions of the topic involved a set of guidelines and a core baseline of functionality that a PWA "should" have.

And once again - allow me to get on my soap box. The set of guidelines that follows will be a bit intense. Remember - you are not required to do every single thing on this list!! Any one thing you do will be an improvement.

The Guidelines

Now it's time to get into the nitty gritty. Let's go over the basic list of what a PWA entails. This list was sourced from the Wikipedia article on PWA. Try to remember that these guidelines are just that - guidelines. Exactly how these are implemented will vary wildly depending on what you are building.

• Progressive: We already covered this. Basically using the latest and greatest web technologies and ensuring that your code gracefully handles browsers that can't do what you want. Note - using a "Best Viewed in Chrome" button does not make your website progressive. It just makes you look stupid. Don't do that.
• Responsive: Responsive design is design that handles both a large desktop view as well as a smaller form mobile view. It also means everything in between as well, for example, tablets. Basically design that can handle various different form factors. Don't forget some people browse content on TVs and watches.
• Works Offline, or in Poor Networks: I think most people grok the "works offline" aspect, but the "poor networks" aspect is something else entirely. Your app should make it's best effort to recognize not only that it is online, but what kind of connection it may have. How important that is depends on what you're doing of course. If you are just loading text data back and forth, a lower quality network may not matter as much. An Instagram-clone however will need more speed to push large images around. There's no magic bullet here. Remember that your dev tools (and I'll be covering dev tools more later) include support for testing different network conditions.
• App-Like: This is my least favorite of the guidelines. Not because I think it's wrong of course, just a bit vague. In general I think you can take it to mean that the app consists of a shell where only changing content is loaded. For example, on Twitter's PWA site the header stays consistently and tweets are loaded dynamically as you scroll. On the flip side, I'll again remind remind folks that "non apps" are welcome to join the PWA party as well.
• Fresh: This simply refers to doing your best to ensure the most up to date content possible is loaded. For a weather app this is crucial. For a stock app, even more so. For a content site you can get by (maybe) with older content, at least initially, and progressively update it as the website is browsed by the end user.
• Safe: Use HTTPS. Please stop using HTTP. There are so many easy, free, simple ways to do this it is almost ridiculous not to. Some browsers (like the somewhat popular Chrome one) are actually now flagging HTTP sites as inherently insecure. All the cool kids are doing HTTPS, don't you want to be cool? Don't you want Chrome to like you? Of course you do! On a serious note, while I don't think end users are very cognizant of HTTP versus HTTPS, I think that will change over time as more browsers adopt Chrome's behavior and make HTTP sites feel like the scummier parts of the net. (You know what I mean. Don't pretend you don't.)
• Discoverable: This refers to certain things the website can do to "announce" itself as a PWA. I'll be covering this later when we get into things like the app manifest and service workers.
• Re-Enageable: This means an app that can ask the user to return to it via notifications. Because that's what users want - they want your app to constantly tell you to come back, look at what you're missing, watch as your friends enjoy life and you sit alone in your cold dark apartment… wow that got dark, sorry. So yes, this is yet another thing that I'll point out as something you should consider as optional. If it makes sense for your site to inform the user that something new has arrived, then you can use technology like push notifications to bring them back. If this doesn't make sense for your site, for the love of God please don't add this just because.
• Installable: Allow users to "install" your site to the desktop or home screen. This is mainly done via app manifests, but when we get to this section, I'll cover alternative ways of supporting this as well.
• Linkable: Congratulations - you've built a website so it's already linkable. I would add that if you use a SPA framework, ensure you're doing the right thing to update the URL on navigation so a user can bookmark and later return to where they are. But in general, this is a benefit you get free, and it is one of the most significant benefits over native apps. Users have nothing to install - they simply go right to your content in their browser.

The Tech Stack

So now you know what should be in a PWA, but how is it actually implemented? In general, the tech stack consists of three aspects.

First is the Manifest, or App Manifest. Luckily this is just a JSON file. You don't need to be a JavaScript expert to write one. This file basically supports the "Discoverable" item above and allows for better "add to home screen/desktop" support.

The second item is the Service Worker. The good news here is that if you think writing a JSON file is beneath your awesome JavaScript skills, then you'll love writing the service worker. Yeah, it's tough. Not impossible, not by a long shot. But certainly it can get a bit complex. This series will walk through some of the basics, talk about debugging, and then provide some ideas for how to simplify this with libraries. The Service Worker is what allows for the more advanced aspects of PWAs like caching, push notifications, and background sync.

And finally - the App Shell. This is the "App-Like" guideline mentioned above and I won't repeat my concerns about this. I think if you are building a proper app, then you absolutely want to use a framework that supports this. Every major JavaScript framework (Vue, Angular, React, etc) makes this trivial. If you're building something more content-heavy, then this may not make as much sense. As you can tell, I'm definitely torn about this and I'd love to hear people explain why I'm wrong.

Off We Go!

And that's it for the first installment. In the next article, I'll start introducing you to the manifest. I'll cover what it supports, how to add it, and how to confirm it's working correctly. Let me know what you think so far by leaving a comment below.