I endorse this message.
This manifesto is intended as a personal response to the current state of the web. It is a statement of intent and a call to arms, inviting you, the reader, to go forth and build humane websites, and to resist the erosion of the web we know and love.
Much as I appreciate the optimism of this evaluation, I don’t hold out much hope that people’s expectations are going to change any time soon:
Indeed, when given a choice, users will opt for the [native] app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.
Nonetheless, this is a level-headed look at what a progressive web app is, mercifully free of hand-waving:
- App is served through HTTPS.
- App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
- App has a registered service worker with a fetch event handler. (More on this later too.)
I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?
If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.
I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
It’s wonderfully practical!
I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And there’s this excellent explanation which could just as well apply to the priorty of constituencies:
That is, while there is value in the items on the right, we value the items on the left more.
Yes! That’s the spirit!
Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).
Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.
Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.
It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.
I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.
Best of all, I got to put my new-found knowledge to use! Here’s how…
The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.
In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.
So I added a back button in the navigation interface. It only appears on small screens.
Do you see the assumption I made?
I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?
Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.
So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).
I was alerted to this issue on The Session:
It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.
Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:
.goback {
display: none;
}
@media (display-mode: standalone) {
.goback {
display: inline;
}
}
Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.
Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?
If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!
We invite software developers to do their part, by
- ensuring their users can conveniently obtain a link to the currently open or selected resource via a user interface; and
- providing an application programming interface (API) to obtain or construct a link to that resource (i.e., to get its address and name).
There’s a good discussion here (kicked off by Jen) about providing different theme-color values in a web app manifest to match prefers-color-scheme in media queries.
I think I’ve found some more strange service worker behaviour in Chrome.
It all started when I was checking out the very nice new redesign of WebPageTest. I figured while I was there, I’d run some of my sites through it. I passed in a URL from The Session. When the test finished, I noticed that the “screenshot” tab said that something was being logged to the console. That’s odd! And the file doing the logging was the service worker script.
I fired up Chrome (which isn’t my usual browser), and started navigating around The Session with dev tools open to see what appeared in the console. Sure enough, there was a failed fetch attempt being logged. The only time my service worker script logs anything is in the catch clause of fetching pages from the network. So Chrome was trying to fetch a web page, failing, and logging this error:
The service worker navigation preload request failed with a network error.
But all my pages were loading just fine. So where was the error coming from?
After a lot of spelunking and debugging, I think I’ve figured out what’s happening…
First of all, I’m making use of navigation preloads in my service worker. That’s all fine.
Secondly, the website is a progressive web app. It has a manifest file that specifies some metadata, including start_url. If someone adds the site to their home screen, this is the URL that will open.
Thirdly, Google recently announced that they’re tightening up the criteria for displaying install prompts for progressive web apps. If there’s no network connection, the site still needs to return a 200 OK response: either a cached copy of the URL or a custom offline page.
So here’s what I think is happening. When I navigate to a page on the site in Chrome, the service worker handles the navigation just fine. It also parses the manifest file I’ve linked to and checks to see if that start URL would load if there were no network connection. And that’s when the error gets logged.
I only noticed this behaviour because I had specified a query string on my start URL in the manifest file. Instead of a start_url value of /, I’ve set a start_url value of /?homescreen. And when the error shows up in the console, the URL being fetched is /?homescreen.
Crucially, I’m not seeing a warning in the console saying “Site cannot be installed: Page does not work offline.” So I think this is all fine. If I were actually offline, there would indeed be an error logged to the console and that start_url request would respond with my custom offline page. It’s just a bit confusing that the error is being logged when I’m online.
I thought I’d share this just in case anyone else is logging errors to the console in the catch clause of fetches and is seeing an error even when everything appears to be working fine. I think there’s nothing to worry about.
Update: Jake confirmed my diagnosis and agreed that the error is a bit confusing. The good news is that it’s changing. In Chrome Canary the error message has already been updated to:
DOMException: The service worker navigation preload request failed due to a network error. This may have been an actual network error, or caused by the browser simulating offline to see if the page works offline: see https://w3c.github.io/manifest/#installability-signals
Much better!
This in an intriguing promise (there’s no code yet):
A PWA typically requires writing a service worker, an app manifest and a ton of custom code. Progressier flattens the learning curve. Just add it to your html template — you’re done.
I worry that this one line of code will pull in many, many, many, many lines of JavaScript.
I got an email a little while back from Michael at Repeater Books asking me if I wanted an advance copy of Abolish Silicon Valley: How to Liberate Technology From Capitalism by Wendy Liu. Never one to look a gift horse in the mouth, I said “Sure!”
I’m happy to say that the book is most excellent …or at least mostly excellent.
Contrary to what the book title—or its blurb—might tell you, this is a memoir first and foremost. It’s a terrific memoir. It’s utterly absorbing.
Just as the most personal songs can have the most universal appeal, this story feels deeply personal while being entirely accessible. You don’t have to be a computer nerd to sympathise with the struggles of a twenty-something in a start-up trying to make sense of the world. This well-crafted narrative will resonate with any human. It calls to mind Ellen Ullman’s excellent memoir, Close to the Machine—not a comparison I make lightly.
But as you might have gathered from the book’s title, Abolish Silicon Valley isn’t being marketed as a memoir:
Abolish Silicon Valley is both a heartfelt personal story about the wasteful inequality of Silicon Valley, and a rallying call to engage in the radical politics needed to upend the status quo.
It’s true that the book finishes with a political manifesto but that’s only in the final chapter or two. The majority of the book is the personal story, and just as well. Those last few chapters really don’t work in this setting. They feel tonally out of place.
Don’t get me wrong, the contents of those final chapters are right up my alley—they’re preaching to the converted here. But I think they would be better placed in their own publication. The heavily-researched academic style jars with the preceeding personal narrative.
Abolish Silicon Valley is 80% memoir and 20% manifesto. I worry that the marketing isn’t making that clear. It would be a shame if this great book didn’t find its audience.
The book will be released on April 14th. It’s available to pre-order now. I highly recommend doing just that. I think you’ll really enjoy it. But if you get mired down in the final few chapters, know that you can safely skip them.
There’s an interesting thread on Github about the tongue-twistingly named beforeinstallpromt JavaScript event.
Let me back up…
Progressive web apps. You know what they are, right? They’re websites that have taken their vitamins. Specifically, they’re responsive websites that:
The web app manifest—a JSON file of metadata—is particularly useful for describing how your site should behave if someone adds it to their home screen. You can specify what icon should be used. You can specify whether the site should launch in a browser or as a standalone app (practically indistinguishable from a native app). You can specify which URL on the site should be used as the starting point when the site is launched from the home screen.
So progressive web apps work just fine when you visit them in a browser, but they really shine when you add them to your home screen. It seems like pretty much everyone is in agreement that adding a progressive web app to your home screen shouldn’t be an onerous task. But how does the browser let the user know that it might be a good idea to “install” the web site they’re looking at?
The Samsung Internet browser does ambient badging—a + symbol shows up to indicate that a website can be installed. This is a great approach!
I hope that Chrome on Android will also use ambient badging at some point. To start with though, Chrome notified users that a site was installable by popping up a notification at the bottom of the screen. I think these might be called “toasts”.
Needless to say, the toast notification wasn’t very effective. That’s because we web designers and developers have spent years teaching people to immediately dismiss those notifications without even reading them. Accept our cookies! Sign up to our newsletter! Install our native app! Just about anything that’s user-hostile gets put in a notification (either a toast or an overlay) and shoved straight in the user’s face before they’ve even had time to start reading the content they came for in the first place. Users will then either:
X in the corner of the notification.A tiny fraction of users might actually click on the call to action, possibly by mistake.
Chrome didn’t abandon the toast notification for progressive web apps, but it did change when they would appear. Rather than the browser deciding when to show the prompt—usually when the user has just arrived on the site—a new JavaScript event called beforeinstallprompt can be used.
It’s a bit weird though. You have to “capture” the event that fires when the prompt would have normally been shown, subdue it, hold on to that event, and then re-release it when you think it should be shown (like when the user has completed a transaction, for example, and having your site on the home screen would genuinely be useful). That’s a lot of hoops. Here’s the code I use on The Session to only show the installation prompt to users who are logged in.
The end result is that the user is still shown a toast notification, but at least this time it’s the site owner who has decided when it will be shown. The Chrome team call this notification “the mini-info bar”, and Pete acknowledges that it’s not ideal:
The mini-infobar is an interim experience for Chrome on Android as we work towards creating a consistent experience across all platforms that includes an install button into the omnibox.
I think “an install button in the omnibox” means ambient badging in the browser interface, which would be great!
Anyway, back to that thread on Github. Basically, neither Apple nor Mozilla are going to implement the beforeinstallprompt event (well, technically Mozilla have implemented it but they’re not going to ship it). That’s fair enough. It’s an interim solution that’s not ideal for all reasons I’ve already covered.
But there’s a lot of pushback. Even if the details of beforeinstallprompt are troublesome, surely there should be some way for site owners to let users know that can—or should—install a progressive web app? As a site owner, I have a lot of sympathy for that viewpoint. But I also understand the security and usability issues that can arise from bad actors abusing this mechanism.
Still, I have to hand it to Chrome: even if we put the beforeinstallprompt event to one side, the browser still has a mechanism for letting users know that a progressive web app can be installed—the mini info bar. It’s not a great mechanism, but it’s better than nothing. Nothing is precisely what Firefox and Safari currently offer (though Firefox is experimenting with something).
In the case of Safari, not only do they not provide a mechanism for letting the user know that a site can be installed, but since the last iOS update, they’ve buried the “add to home screen” option even deeper in the “sharing sheet” (the list of options that comes up when you press the incomprehensible rectangle-with-arrow-emerging-from-it icon). You now have to scroll below the fold just to find the “add to home screen” option.
So while I totally get the misgivings about beforeinstallprompt, I feel that a constructive alternative wouldn’t go amiss.
And that’s all I have to say about that.
Except… there’s another interesting angle to that Github thread. There’s talk of allowing sites that are launched from the home screen to have access to more features than a site inside a web browser. Usually permissions on the web are explicitly granted or denied on a case-by-case basis: geolocation; notifications; camera access, etc. I think this is the first time I’ve heard of one action—adding to the home screen—being used as a proxy for implicitly granting more access. Very interesting. Although that idea seems to be roundly rejected here:
A key argument for using installation in this manner is that some APIs are simply so powerful that the drive-by web should not be able to ask for them. However, this document takes the position that installation alone as a restriction is undesirable.
I understand that Chromium or Google may hold such a position but Apple’s WebKit team may not necessarily agree with such a position.
Automatically generates icons and splash screens based on Web App Manifest specs and Apple Human Interface Guidelines. Updates manifest.json and index.html files with the generated images.
A handy command line tool. Though be aware that it will generate the shit-ton of link elements for splash screens that Apple demands you provide for a multitude of different screen sizes.
Well, this could be very handy for Huffduffer!
Another directory of progressive web apps, this time maintained by Google.
I quite like the way it links through to a Lighthouse report. Here’s the listing for The Session, for example, and here’s the corresponding Lighthouse report.
What an excellent question! And what an excellent bit of sleuthing to get to the bottom of it. This is like linguistic spelunking on the World Wide Web.
Oh, and of course I love the little sidenote at the end.
I was just talking about how browser-based games are the perfect use-case for service workers. Andrzej Mazur breaks down how that would work:
I gave a quick talk at the Delta V conference in London last week called Any Site can be a Progressive Web App. I had ten minutes, but frankly I only needed enough time to say the title of the talk because, well, that was also the message.
There’s a common misconception that making a Progressive Web App means creating a Single Page App with an app-shell architecture. But the truth is that literally any website can benefit from the performance boost that results from the combination of HTTPS + Service Worker + Web App Manifest.
See how I define a progressive web app as being HTTPS + service worker + web app manifest? I’ve been doing that for a while. Here’s a post from last year called Progressing the web:
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.
That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page app.
Later I wrote a post called What is a Progressive Web App? where I compared the definition to responsive web design.
Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:
- A fluid layout,
- Fluid images, and
- Media queries.
Likewise, Progressive Web Apps consist of:
- HTTPS,
- A service worker, and
- A Web App Manifest.
There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.
But here’s the thing. Outside of the confines of my own website, it’s hard to find that definition anywhere.
On Google’s developer site, their definition uses adjectives like “reliable”, “fast”, and “engaging”. Those are all great adjectives, but more useful to a salesperson than a developer.
Over on the Mozilla Developer Network, their section on progressive web apps states:
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.
Hmm …I’m not so sure about that comparison to native apps (and I’m a little disturbed that the URL structure is /Apps/Progressive). So let’s click through to the introduction:
PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features.
Okay. Specific technologies. That’s good to hear. But instead of then listing those specific technologies, we’re given another list of adjectives (discoverable, installable, linkable, etc.). Again, like Google’s chosen adjectives, they’re very nice and desirable, but not exactly useful to someone who wants to get started making a progressive web app. That’s why I like to cut to the chase and say:
If you do that, you’ve got a progressive web app. Now, to be fair, there’a lot that I’m leaving out. Your site should be fast. Your site should be responsive (it is, after all, on the web). There’s not much point mucking about with service workers if you haven’t sorted out the basics first. But those three things—HTTPS + service worker + web app manifest—are specifically what distinguishes a progressive web app. You can—and should—have a reliable, fast, engaging website before turning it into a progressive web app.
Jason has been thinking about progressive web apps a lot lately (he should write a book or something), and he said to me:
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.
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.
Lighthouse, PWA Builder, Sonarwhal and other tools that evaluate your site will measure its progressive web app score based on the three defining factors (HTTPS, service worker, web app manifest). Then there’s Android’s Add to Home Screen prompt. Here finally we get a concrete description of what your site needs to do to pass muster:
- Includes a web app manifest…
- Served over HTTPS (required for service workers)
- Has registered a service worker with a fetch event handler
(Although, as of this month, Chrome will no longer show the prompt automatically—you also have to write some JavaScript to handle the beforeinstallprompt event).
Anyway, if you’re looking to turn your website into a progressive web app, here’s what you need to do (assuming it’s already performant and responsive):
That last step might sound like an intimidating prospect, but help is at hand: I wrote Going Offline for exactly this situation.
It’s really great to hear about how Microsoft will be promoting progressive web apps as first-class citizens …but it’s really unhelpful that they’re using this fudgy definition:
Progressive Web Apps are just great web sites that can behave like native apps—or, perhaps, Progressive Web Apps are just great apps, powered by Web technologies and delivered with Web infrastructure.
Although they also give a more technical definition:
Technologically speaking, PWAs are web apps, progressively enhanced with modern web technologies (Service Worker, Fetch networking, Cache API, Push notifications, Web App Manifest) to provide a more app-like experience.
Nice try, slipping notifications in there like that, but no. No, no, no. Let’s not fool ourselves into thinking that one of the most annoying “features” of native apps is even desirable on the web.
If you want to use notifications, fine. But they are absolutely not a requirement for a progressive web app.
(A responsive design, on the other hand, totally is.)
Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.
That’s an impressive turnaround.
Here’s a nice one-sentence definition for the marketing folk:
A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.
But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.
It seems like any new field goes through an inevitable growth spurt that involves “defining the damn thing.” For the first few years of the IA Summit, every second presentation seemed to be about defining what Information Architecture actually is. See also: UX. See also: Content Strategy.
Now it seems to be happening with Progressive Web Apps …which is odd, considering the damn thing is defined damn well.
I’ve written before about the naming of Progressive Web Apps. On the whole, I think it’s a pretty good term, especially if you’re trying to convince the marketing team.
Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:
Likewise, Progressive Web Apps consist of:
There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.
Except, for some reason, that clarity is being lost.
Here’s a post by Ben Halpern called What the heck is a “Progressive Web App”? Seriously.
I have a really hard time describing what a progressive web app actually is.
He points to Google’s intro to Progressive Web Apps:
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.
Those are great descriptions of the benefits of Progressive Web Apps. Perfect material for convincing your clients or your boss. But that appears on developers.google.com …surely it would be more beneficial for that audience to know the technologies that comprise Progressive Web Apps?
Ben Halpern again:
Google’s continued use of the term “quality” in describing things leaves me with a ton of confusion. It really seems like they want PWA to be a general term that doesn’t imply any particular implementation, and have it be focused around the user experience, but all I see over the web is confusion as to what they mean by these things. My website is already “engaging” and “immersive”, does that mean it’s a PWA?
I think it’s important to use the right language for the right audience.
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.