Seriously, though. What is a progressive web app?
I’ve been familiar with the “progressive web app” (PWA) concept for a while now. But there’s always been an itch in the back of my mind about it.
I’ve been to talks at conferences and meetups about the subject. I’ve read the main docs and top-level “what is a PWA” articles. I’ve read Alex Russell’s post, “Progressive Web Apps: Escaping Tabs Without Losing Our Soul” [Posted 06/15/2015], about the discussion between himself and Frances Berriman that originated the term, and Frances’ post, “Naming Progressive Web Apps” [Posted 06/26/2017], about the semantic foofaraw around the term “progressive web app” itself.
And still, I have found it difficult to conclusively, accurately, and concisely define it (based on concrete citation, that is). I see similar confusion across the internet.
One such example — Ben Halpern of dev.to, in a post called “What the heck is a “Progressive Web App”? Seriously.” [Posted 11/06/2017, updated 04/21/2018]:
This morning I went to write an article outlining a few tips about implementing a progressive web app (PWA). But when I went to introduce the topic, I again encountered what was the hardest part about the whole topic in the first place: I have a really hard time describing what a progressive web app actually is.
He captured a lot of my “is this just me?” feels too:
Perhaps PWA is meant to be inclusive of a lot of technical approaches, so they need to be vague. This might be okay if it were just the source docs that were this way, but I feel like alternative introductions and how-tos scattered across the web have latched on to this vague language and the confusion has proliferated.
It’s socially hard to say “hold on, I don’t understand any of that”, because you don’t know if everybody else just gets it and you’re the stupid one. In the PWA space, I really do feel like there’s a lot of people nodding along assuming everyone else understands what a PWA is and they must be missing something. You know, imposter syndrome. [emphasis added]
Another such example is the uncertainty acknowledged in this blog post from Microsoft [Posted 02/06/2018] — a top-page hit when Googling “what is a progressive web app”:
The excitement about PWAs in the developer community is almost palpable — but amongst all that excitement, it can be hard to pin down a single, concise, authoritative definition of a “Progressive Web App.” [emphasis added]
What had me particularly confused, personally, is that parts of the internet have seemingly coalesced around three baseline requirements for what comprises a progressive web app — and none of them cite where it came from. It’s impressive to me to achieve that level of unofficial, broad accord, given zero citation — it just echoes across the internet. (And the worst part? I’m guilty; I did the same thing in “A Browser-Based, Open Source Tool for Alternative Communication” [Posted 03/14/2018]. And I remember feeling conflicted about it at the time).
Because this time I couldn’t bring myself to divert from this mental rabbit hole, I started looking into:
- The origin of the listing of attributes that constitute a PWA that are generally referenced in docs and posts,
- The origin of the three baseline requirements for a PWA that are generally referenced in docs and posts, and,
- The variation in definitions among the top-level search results for “progressive web app”
At the end, I’ll post my conclusion of a definition for PWA (for whatever that’s worth).
The general attributes that constitute a PWA
This part is conclusive. In 2015, Alex Russell introduced the term “progressive web app” online. He recounted a conversation between himself and Frances Berriman, in which they “enumerated the attributes of [a] new class of applications” based on the gradual and powerful evolution of modern browsers. Those attributes are, verbatim:
- Responsive: to fit any form factor
- Connectivity independent: Progressively-enhanced with Service Workers to let them work offline
- App-like-interactions: Adopt a Shell + Content application model to create appy navigations & interactions
- Fresh: Transparently always up-to-date thanks to the Service Worker update process
- Safe: Served via TLS (a Service Worker requirement) to prevent snooping
- Discoverable: Are identifiable as “applications” thanks to W3C Manifests and Service Worker registration scope allowing search engines to find them
- Re-engageable: Can access the re-engagement UIs of the OS; e.g. Push Notifications
- Installable: to the home screen through browser-provided prompts, allowing users to “keep” apps they find most useful without the hassle of an app store
- Linkable: meaning they’re zero-friction, zero-install, and easy to share. The social power of URLs matters.
The three baseline criteria for a PWA
The three baseline criteria a site must fulfill in order to qualify as a PWA echo across the web. They are:
- You need to be running under HTTPS.
- You need a Web App Manifest.
- You need a Service Worker.
This in particular is copied verbatim from Aaron Gustafson’s “Yes, That Web Project Should Be a PWA” [Posted 08/30/2017]. I asked Aaron where, specifically, that apparently canonical list of three originates (beyond the vague, general internet pseudo-consensus).
He pointed me to Jeremy Keith, where I re-read, among others, his post, “HTTPS + service worker + web app manifest = progressive web app”. In it, he cites an older post of his own, “Progressing the web”, where he said:
Literally any website can be a progressive web app:
- switch over to HTTPS,
- add a JSON manifest file with your metacrap, and
- add a service worker.
Later on, in response to a tweet from Jason Grigsby asking the same question I’m asking now — “I agree with you on the three things that comprise a PWA, but as far as I can tell, you’re the first to declare it as such. Am I wrong about that?” He responded:
I was quite surprised by that. I always assumed that I was repeating the three ingredients of a progressive web app, not defining them. But looking through all the docs out there, Jason might be right. It’s surprising because I assumed it was obvious why those three things comprise a progressive web app — it’s because they’re testable.
So, nothing conclusive on the origin. (So far.)
Variation in definitions among the top-level search results for “progressive web app”
While on this bender, I thought I’d review the variations in definitions of the top five Google search results for “progressive web app”. And thank god I did because I found a gem (queue suspense).
Progressive Web Apps are user experiences that have the reach of the web, and are:
Reliable — Load instantly and never show the downasaur, even in uncertain network conditions.
Fast — Respond quickly to user interactions with silky smooth animations and no janky scrolling.
Engaging — Feel like a natural app on the device, with an immersive user experience.
Progressive Web Apps are experiences that combine the best of the web and the best of apps. They are useful to users from the very first visit in a browser tab, no install required. As the user progressively builds a relationship with the app over time, it becomes more and more powerful. It loads quickly, even on flaky networks, sends relevant push notifications, has an icon on the home screen, and loads as a top-level, full screen experience.
This resource also lists the canonical list of attributes, but adds a tenth:
Progressive — Works for every user, regardless of browser choice because it’s built with progressive enhancement as a core tenet.
Progressive Web Apps (PWAs) are web applications that are regular web pages or websites, but can appear to the user like traditional applications or native mobile applications. The application type attempts to combine features offered by most modern browsers with the benefits of a mobile experience.
The Wikipedia entry lists web manifest and service workers as “commonly used technologies” to support the defined characteristics of a PWA (which it does cite to Berriman and Russell).
Then, lo, buried in a footnote, the Wikipedia entry attributes the technical baseline criteria for a PWA to none other than (🥁) Alex Russell, from his post: “What, Exactly, Makes Something A Progressive Web App?” [Posted 09/12/2016]. (This is the gem, by the way 💎).
This is surprising to me for a couple reasons. One, how had I not seen this cited anywhere before? And two, how ironic that he works at Google, and as far as I can tell, the Google resources are one of the ones that don’t specifically cite these baseline requirements.
Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.
PWAs should be discoverable, installable, linkable, network independent, progressive, re-engageable, responsive, and safe.
Like the Google Developers: Your First Progressive Web App page, this list adds “progressive”, and contains all of the other attributes from the Russell/Berriman list, except for “Fresh” and “App-like”, for some reason?
A progressive web application takes advantage of the latest technologies to combine the best of web and mobile apps. Think of it as a website built using web technologies but that acts and feels like an app. Recent advancements in the browser and in the availability of service workers and in the Cache and Push APIs have enabled web developers to allow users to install web apps to their home screen, receive push notifications and even work offline.
It also recites the same characteristics, linking back to the Google Developers resource. It also cites PWAs as being “originally proposed by Google”.
The end of this unnecessary journey
Now, finally, what I will take forward as my personal definition of a PWA:
“Progressive web app” (PWA) is both a general term for a new philosophy toward building websites and a specific term with an established set of three explicit, testable, baseline requirements.
As a general term, the PWA approach is characterized by striving to satisfy the following set of attributes:
- Connectivity independent
As a specific term, websites can be tested against the following three baseline criteria to qualify as a PWA:
- It must run under HTTPS.
- It must include a Web App Manifest.
- It must implement a service worker.
PWAs are apps delivered through the web (as opposed to native apps, packaged and deployed through stores). As Alex Russell said:
…they’re just websites that took all the right vitamins.
Timeline of referenced posts:
- “Progressive Web Apps: Escaping Tabs Without Losing Our Soul” [Posted 06/15/2015]
- “What, Exactly, Makes Something A Progressive Web App?” [Posted 09/12/2016]
- “Naming Progressive Web Apps” [Posted 06/26/2017]
- “Progressing the web” [Posted 06/27/2017]
- “Yes, That Web Project Should Be a PWA” [Posted 08/30/2017]
- “What the heck is a “Progressive Web App”? Seriously.” [Posted 11/06/2017, updated 04/21/2018]
- “Welcoming Progressive Web Apps to Microsoft Edge and Windows 10” [Posted 02/06/2018]
- “HTTPS + service worker + web app manifest = progressive web app” [Posted 05/16/2018]
Sidenote: I mostly drafted this post on a plane, with no wifi. I realized I had forgotten to re-open one of Jeremy Keith’s posts I meant to reference. I clicked it, and there it was, cached and ready for my offline perusal 🙃