Many, many years ago, Tim Berners-Lee wrote this page of answers to (genuinely) frequently asked questions he got from school kids working on reports. I absolutely love the clear straightforward language he uses to describe concepts like hypertext, packet switching, and HTTP.
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.
Well, I guess it’s time to change all my locally-hosted sites from
.dev domains to
.test. Thanks, Google.
A fantastic piece by Aaron who—once again—articulates what I’ve been thinking:
Your site—every site—should be a PWA.
He clearly explains the building blocks of progressive web apps—HTTPS, a manifest file, and a service worker—before describing different scenarios for different kinds of sites:
Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives.
The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
Tell it, brother!
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!
This looks like a useful tool, not just for testing locally-hosted sites (say, at a device lab), but also for making locally-hosted sites run on HTTPS so you can test service workers.
Charlotte’s step-by-step account of setting up a Node server is going to be invaluable if and when I get around to dipping my toes in those waters.
Turning your existing website into a progressive web “app”—a far more appealing prospect than trying to create an entirely new app-shell architecture:
…they are an enhancement of your existing website which should take no longer than a few hours and have no negative effect on unsupported browsers.
Things are looking good for HTTPS.
Scott runs through the latest improvements to the Filament Group website. There’s a lot about HTTP2, but also a dab of service workers (using a similar recipe to my site).
A cute explanation of different browser caches:
- memory cache,
- service worker cache,
- disk cache, and
- push cache.
Details of The Guardian’s switch to HTTPS.
A nice little walkthrough of a straightforward Service Worker for a content-based site, like a blog.
Slowly but surely the web is switching over to HTTPS. The past year shows a two to threefold increase.
One more reason to make the switch to HTTPS.