Chapter 1. Defining Progressive Web Apps

They’re just websites that took all the right vitamins.

—Alex Russell (http://bkaprt.com/pwa/01-01/)

Let’s get this out of the way up front: the phrase progressive web app has become a bit of a buzzword. Its meaning often changes based on whom you are speaking with and what features they are most interested in.

And who can blame them? In 2015, Google’s developer page on progressive web apps started with a list of ten characteristics, but was reduced to six just a year later (http://bkaprt.com/pwa/01-02/). Later the page added three characteristics—Reliable, Fast, and Engaging—none of which were in the original list of ten. Not content with that definition, at the 2017 Chrome Dev Summit, Google added “Integrated” to the list, to create the acronym “F.I.R.E.” (http://bkaprt.com/pwa/01-03/).

When Google, one of the main proponents of progressive web apps, has changed its definition multiple times, it’s no surprise that people are confused about what a progressive web app really is. And while F.I.R.E. is a great acronym, I’m not sure “Fast, Integrated, Reliable, and Engaging” offers much clarification.

Evolving definitions are fairly typical for new technologies. Back when HTML5 was considered buzzworthy, people would often talk enthusiastically about HTML5 features that were technically part of CSS3. Similarly, people often ascribe to progressive web apps features that are not technically part of the “official” definition.

Some of this fuzziness is intentional. Frances Berriman, who, along with Alex Russell, coined the phrase progressive web apps, said of the name, “It’s marketing, just like HTML5 had very little to do with actual HTML. PWAs are just a bunch of technologies with a zingy-new brandname that keeps the open web going a bit longer” (http://bkaprt.com/pwa/01-04/).

So there’s hype around progressive web apps—but you can use it to your advantage. When people get excited about progressive web apps, that’s an opportunity to open minds about what is possible on the modern web. Organizations that pursue progressive web apps often end up reinvesting in the web, addressing longstanding issues like performance and user engagement. What Berriman and Russell did in naming a developing trend is similar to what Ethan Marcotte did for responsive web design: they gave everyone something to get excited about.

An amorphous definition can be helpful when drumming up interest in creating a progressive web app. But when your team sits down to start planning your PWA, you’ll need a more concrete definition of what to build.

The Original Definition

For many years, companies have tried to enable developers to create app-like experiences using web technology. Products ranging from Adobe AIR and PhoneGap to Windows Hosted Apps and Electron have sought to leverage the power of the web to create apps that exist outside the browser. Many apps have been created using these technologies, but each suffered the same problem: while they were built using the web, they weren’t of the web.

In order to provide that app-like experience, these technologies were forced to give up two of the most powerful features of the web: the ability to link to anything, and the ability to run in any browser on any device. The tradeoffs necessary to make something feel like an app created something that was separated from the web.

In 2015, Berriman and Russell observed a new class of websites that were providing substantially better user experiences than traditional web applications. These new websites took advantage of a natural evolution in browser capabilities to create something that felt revolutionary: they escaped from the browser’s tabs to live as their own apps, but retained the ubiquity and linkability that make the web what it is.

Berriman and Russell called these new websites progressive web apps, and documented nine defining characteristics (http://bkaprt.com/pwa/01-01/). These emergent sites were:

• Responsive. They leveraged responsive web design techniques to adapt the experience to whatever device or screen size a person might use.
• Connectivity independent. Portions of each website continued to function offline or on poor networks.
• App-like. They used app shell, animated transitions, and other touches to make it feel more “appy.” (We’ll talk about what that means more in Chapter 3.)
• Fresh. The app updated behind the scenes so it was always current.
• Safe. All traffic to the app was encrypted to prevent prying eyes.
• Discoverable. The sites declared that they were apps using a simple text file called a manifest, which search engines and browsers could look for to discover new apps.
• Re-engageable. They used push notifications to send alerts and bring users back into the app.
• Installable. Users could add an icon for the app to their homescreen.
• Linkable. The app could be shared easily, and accessed without having to download and install an app.

A final, key characteristic of progressive web apps is that they are built using progressive enhancement. Progressive enhancement is a web strategy that emphasizes creating a baseline experience that works everywhere, and then enhancing that experience on more capable devices.

What this means is that, while you will have a single progressive web app for all users, each individual’s experience of that app may vary. A progressive web app can adapt based on the capabilities of the device and the permissions the user grants to the app, such as the permission to be on the homescreen.

Still, the definition of progressive web apps has been flexible from the beginning. Even Berriman and Russell deviated from their list of characteristics in that same post, when they highlighted Flipboard as an example, despite it not being responsive.

In fact, few progressive web apps meet all ten characteristics. Instead of thinking of this list as requirements, think of them as aspirations. Over time, our baseline expectations of progressive web apps will undoubtedly grow, but for now, you can have a successful progressive web app without checking every box on the list.

The Technical Definition

If Berriman and Russell’s definition is aspirational, and Google’s F.I.R.E. acronym is so broad as to be meaningless, how do we determine if something is a progressive web app or not?

Jeremy Keith proposed a more technical view in a 2017 blog post (http://bkaprt.com/pwa/01-05/). He defined progressive web apps by the inclusion of three technical features:

1. HTTPS: Progressive web apps must be served over a secure server using HTTPS. Most of the power in progressive web apps comes from service workers, which can only be used over HTTPS. If your current website is not using HTTPS, you need to move to HTTPS before you can do anything else.
2. A service worker: This powerful new technology allows web developers to intercept and control how a web browser handles its network requests and asset caching. With service workers, web developers can create reliably fast web pages and offline experiences.
3. A web app manifest: This short file ensures that progressive web apps are discoverable. It describes the name of the app, the start URL, icons, and all of the other details necessary to transform the website into an app.

A progressive web app may have more features than just these three, but it can’t claim to be a progressive web app without them.

This nuts and bolts definition is useful for determining what qualifies as a progressive web app, but it’s unlikely to inspire (or persuade your organization to open its purse strings). Instead, treat this definition as the minimum bar.

The vision of what a progressive web app can be is much broader. Think of progressive web apps as enabling experiences that previously required the development of a native application. Now, you can provide advanced features—like offline access and push notifications—to anyone who visits your website.

Embrace the Hype

I encourage you to embrace the ambiguous nature of progressive web apps. Ultimately, a strict definition matters much less than understanding what features make the most sense for your customers and your business. Your progressive web app will be unique to your website and your organization—and, as Jeremy Keith put it, there is value in tailoring how you talk about progressive web apps:

If you’re talking to the business people, tell them about the return on investment you get from Progressive Web Apps.

If you’re talking to the marketing people, tell them about the experiential benefits of Progressive Web Apps.

But if you’re talking to developers, tell them that a Progressive Web App is a website served over HTTPS with a service worker and manifest file. (http://bkaprt.com/pwa/01-05/)

When I was first introduced to the idea of progressive web apps, I admit I was unimpressed. From a technical perspective, there was nothing new here that I hadn’t already been exposed to. I already believed every site should run HTTPS. I was familiar with service workers (and their troubled predecessor, app cache). Manifest files or packaging files had seemingly been around for as long as there had been browsers on mobile phones.

But what was routine to me represented exciting new possibilities for others. When I saw firsthand at a digital marketing conference just how many people were interested in the unique capabilities of PWAs, I changed my perspective. As Alex Russell wrote:

It happens on the web from time to time that powerful technologies come to exist without the benefit of marketing departments or slick packaging. They linger and grow at the peripheries, becoming old-hat to a tiny group while remaining nearly invisible to everyone else. Until someone names them. (http://bkaprt.com/pwa/01-06/)

In naming progressive web apps, Berriman and Russell opened the door for organizations to revisit what their website can and should do. And if you’re wondering how to spark that conversation at your organization, look no further than the next chapter.