First, a Little Bit of History

Google and other browser vendors add special features to their browsers all the time, striving to provide more tools developers can use to enhance the web. In 2015, a designer named Frances Berriman and a Google Chrome engineer named Alex Russell coined the term Progressive Web Apps to describe, according to Wikipedia, “apps taking advantage of new features supported by modern browsers, including service workers and web app manifests, that let users upgrade web apps to progressive web apps in their native operating system (OS).”

Google Chrome was the leading browser at the time that supported the required technologies, so Google started heavily promoting this new approach to building web apps.

PWAs Are . . .

Google’s Progressive Web Apps landing page¹ says that PWAs are

• Reliable

• Fast

• Engaging

1. https://developers.google.com/web/progressive-web-apps/

These terms describe a user’s perception of an app, not anything about how the app is built, what technologies it uses, or what it can do. The technologies used to build PWAs enable developers to build web apps that are reliable, fast, and engaging, but only if web developers have the skills and take the time to do it. I think Google’s description is off base, since there are a lot of inexperienced web developers out there who can build PWAs that aren’t reliable, fast, or engaging, but the apps are still PWAs.

So, with that in mind, in this book, PWAs are about the technologies used and how to make them. There are a lot of online articles and books available about how PWAs are more engaging and the impact they’ve had on businesses’ success or revenue; the best place to start for that information is on PWA Stats.²

2. https://www.pwastats.com/

I align with Jeremy Keith’s definition from What Is a Progressive Web App?³ Here’s my take: PWAs are web apps with a little bit of special magic that enable them to act more like mobile apps. It’s the concept of web apps working more like mobile apps that makes PWAs so interesting.

3. https://adactio.com/journal/13098

If you think about most native mobile apps you use on your phone, they

• Are installable from the phone platform’s public app store (and enterprise stores for employee apps), putting an app icon on the device’s home screen.

• Will load and operate (although in a potentially limited fashion) regardless of whether the device has network connectivity. The app’s UI is embedded in the application binary and loads locally when you open the app (pulling data from the network when it can).

• Can run in the background, even doing things or processing data while you’re doing something else on the device.

• Can receive push notifications (messages sent to the device or an app from an external system).

• With some extra work, can even deliver a rich and robust offline experience, caching new records for upload later and synchronizing data with a server-based app.

Does that describe many of the mobile apps you use today? Does your email (or fill in another app name here) app work regardless of whether the device has network connectivity? If you turn off the radio and open the app, does the app’s UI open and display much of the data that was there earlier? When you send a message while offline, does the app queue the data for transmission later? Does the app receive notifications (like when new mail is available)? Yeah, I thought so; those are core capabilities of modern mobile apps.

Turning to PWAs:

• PWAs are installable: mobile and desktop users can quickly install them on their phone’s home screen or desktop using an installation UI provided in the app. Mobile phones have pretty much always had the ability to copy a web site’s URL to the device’s home screen, but installing the app is better. I explain more about it in Chapter 2.

• PWAs cache the app’s core UI on the local device, so when the user opens the app, the UI loads quickly before the app tries to go out and get updated data from the network. Consequently, PWAs feel snappier than traditional web apps.

• PWAs run background tasks, enabling resource caching and background processing. Traditional web apps can’t do this (well, they can, but it takes a lot of handcrafted code or a third-party library).

• PWAs can receive push notifications from a backend server regardless of whether the app is running.

When Apple announced the iPhone, they famously failed when they assumed developers would be happy having the ability to build web apps only for the platform. Steve Jobs and company arrogantly assumed the browser was enough and could accommodate most app needs. The developer community quickly rebelled, forced Apple’s hand, and that’s how we got the ability to code native apps on iOS.

They rebelled because even though the Safari was quite capable on iOS, and Apple provided some great developer tools (no, not Xcode, anyone remember Dashcode?⁴), there were things that app developers just couldn’t do in the browser. These limitations were also the motivation for the PhoneGap project (which later became Apache Cordova); the project started specifically to enable cross-platform mobile development and give browser developers access to device capabilities that weren’t, at the time, available in the native browser.

4. https://en.wikipedia.org/wiki/Dashcode

Over the years, many of those capabilities made it into the browser through open standards covering things like the device accelerometer, camera, compass, microphone, and much more. Browser apps became more capable, but the few final requirements giving the browser equal footing with native mobile apps were—and this should sound familiar—the capabilities to install a web app on a device, cache code and content locally, run background tasks (even when the app isn’t running), and receive push notifications. The technologies enabling PWAs deliver those final required capabilities to the browser; and, with these capabilities in place, a web app can now act more like a native app.

Making a Progressive Web App

Several technologies enable PWAs; without them, a web app simply can’t be a PWA. Those technologies are web app manifest files, service workers, and Hypertext Transfer Protocol Secure (HTTPS) or, more accurately, HTTP over Transport Layer Security (TLS). HTTPS enables secure communication between a client and server and isn’t a topic I cover in this book except to describe later that it’s required for most PWA capabilities and I explain why. The following chapters describe in detail how to use web app manifest files and service workers to build a PWA. For now, it’s good to know that web app manifest files enable installation of a web app on the local system running the app, and service workers make everything else PWAs do possible.

Table 1.1 lists the app capabilities from the previous section mapped against the PWA technologies that enable them.

A developer must do a lot of work to make a web site interesting, engaging, and useful. This means crafting the site’s pages so they look good and work well on screens or browser windows of varying dimensions (width and height). Web developers must take the client-side browser’s capabilities into account when building these sites, and many developers deliver different capabilities in their sites based on what does or doesn’t work in the browser used at runtime. Some mobile browsers (like the ones on feature phones) can’t process a lot of client-side code, so JavaScript may be disabled or have limited capabilities on that device.

The process developers use to build web pages for these scenarios is called progressive enhancement, where the developer focuses on the content first, then layers on additional functionality for more capable browsers. This means that the app simply works, displaying the required content, regardless of whether the browser supports the extra bells and whistles (like fancy CSS transforms) the developer added for more robust browsers. If those capabilities are there, then the user gets the full experience. If they’re not, the user can at least view the content.

Web apps are more interactive, like Wikipedia (web site) vs. Gmail (web app). Web apps use client-side scripting languages such as JavaScript (or its sister language TypeScript) to deliver a more dynamic and exciting client-side experience. With a web app, when you first hit the app’s URL, the app’s shell downloads and renders before the app goes out to the server for the app’s data.

You can see an example of this in Figure 1.2. The app shell consists of the side navigation and the top button bar, while the content in the content area (bound within the orange border) changes dynamically based on the choices the user makes in the app.

PWAs progressively enhance web apps—that’s, um, why they’re called Progressive Web Apps.

So, let’s assume we have a dynamic web app that’s all about user interaction and dynamic data. The app requires a more capable browser and certainly means that there’s JavaScript involved (to deliver the dynamic nature of the app). The app runs in the browser and uses the system’s network connection to download the shell, then, or perhaps in parallel, it retrieves the app’s data from a server. When the browser running the app doesn’t have network connectivity, the browser displays a spinner or an error message, and the user simply can’t use the app.

True to PWA’s progressive moniker, you’ll enhance the app when you add a web manifest file to enable client-side installation and add a service worker to enable caching, background processing, and support for push notifications. On browsers that support those capabilities, the PWA becomes installable and lets the user run the app when there’s no network connection (service worker caching), holds new or updated records for upload later when there’s a network connection (service worker caching coupled with background processing), and notifies users when new push messages arrive (service worker background processing).

On systems that don’t support web manifest files and/or service workers? The app works the same way it did before you added the web manifest file or service worker to the app. When you access the app, the app content and data are requested in real time from one or more servers.

PWA Market Impact

So, what impacts are PWAs having in the market? Development organizations quickly adopted the technology because the progressive enhancement nature of the approach enables development teams to dramatically affect performance (for any user running a browser that supports it) for their users with just a few small, simple changes. When users run the app on a browser that doesn’t support PWA technologies, they won’t notice anything different—the app simply continues to work as it always had.

Web app performance, especially on mobile devices, suddenly seems better for some apps. That’s because many app developers implement web manifest files and service workers, and these apps now actively manage their client-side behavior (using background processing and caching) to the user’s benefit.

Users engage more with PWA-enabled apps. That’s just because the apps are snappier (load faster) and work even when the mobile device its running on doesn’t have a network connection. The app might not have all its features when offline, but it still works, and that’s likely all that it takes to make users happy.

Modern web application frameworks and cross-platform development tools adopted PWAs in a big way. For example, React, a very popular JavaScript library for building user interfaces (UIs) (their words, not mine), preloads its default sample project with a service worker automatically. It disables it by default, but all you must do to turn a React app into a PWA is change one line of code, as described in Listing 1.1.

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<App />, document.getElementById('root'));

// if you want your app to work offline and load faster, you
// can change unregister() to register() below. Note this comes
// with some pitfalls. Learn more about service workers:
// https://bit.ly/CRA-PWA
serviceWorker.unregister();

I’ve been doing a lot of work lately using the Ionic Framework. Ionic is a cross-platform UI and component framework for building mobile and desktop apps. Until a short time ago, Ionic apps were typically built using Angular, but the Ionic team recently switched to web components and Stencil (their open web component compiler) and published a PWA Toolkit that delivers a PWA-first approach to web apps.

Most important, PWAs are easier (much, much easier) to create than native mobile apps. That means these apps cost less to make and maintain. When you package a PWA in an Apache Cordova, Ionic Capacitor, or GitHub Electron app, you address the needs of users who want a native version for mobile devices or desktop computers.

The technology is so popular that research firm Gartner predicts that by 2020, 50% of consumer mobile apps will be PWAs (I would give you an online reference for this, but that statement is everywhere online). But you knew that, right? You already purchased, borrowed, or stole this book to learn how to create PWAs.

PWAs and App Stores

Developers build native mobile apps for many reasons, but one of them is so that they can distribute their apps through the mobile device platform’s public app store. While you can install a PWA by just opening a web app in the mobile browser (you’ll learn all about this in the next chapter), the mobile platform vendors trained their users to look for apps in the app stores. This means that users looking for your app are going to look for it in their phone’s app store first.

Some interesting things are happening in this space. In early 2019, Google announced Trusted Web Activity⁵ (TWA) for Android. TWA enables developers to bundle a PWA into a native mobile app for Android. A TWA is essentially a chromeless (no browser UI), full-screen Chrome browser inside an Android app. With it, you get a PWA packaged with a browser in a native app—fresh and ready for deployment through the Google Play Store.

5. https://developers.google.com/web/updates/2019/02/using-twa

Microsoft took a different approach, announcing in mid-2018 that developers can publish their PWAs to the Microsoft Store. If they don’t publish their app to the store, Microsoft will do it for them anyway (if the PWA meets specific criteria). You’ll learn more about this in Chapter 8, “Assessment, Automation, and Deployment.”

Wrap-Up

In this chapter, I gave you a quick introduction to Progressive Web Apps. You’ll find a lot more material online and many authors who dig deeper into the marketing and engagement side of PWAs. Since this is really a book about service workers, I want to get to coding as quickly as possible.

In the next chapter, I show you all about how to make your PWA installable using service workers and web manifest files. After that, the remainder of the book is all about service workers and everything you can do with them.