Finally, the answer to one of the two hard questions in computer science.
This is a free online video course recorded by Jake a couple of years back. It’s got a really good step-by-step introduction to service workers, delivered in Jake’s typically witty way. Some of the details are a bit out of date, and I must admit that I bailed when it got to IndexedDB, but I highly recommend giving this a go.
There’s also a free course on web accessibility I’m planning to check out.
A step-by-step guide to building progressive web apps. It covers promises, service workers, fetch, and cache, but seeing as it’s from Google, it also pushes the app-shell model.
This is a handy resource but I strongly disagree with some of the advice in the section on architectures (the same bit that gets all swoonsome for app shells):
Start by forgetting everything you know about conventional web design, and instead imagine designing a native app.
Avoid overly “web-like” design.
What a horribly limiting vision for the web! After all that talk about being progressive and responsive, we’re told to pretend we’re imitating native apps on one device type.
What’s really disgusting is the way that the Chrome team are withholding the “add to home screen” prompt from anyone who dares to make progressive web apps that are actually, y’know …webby.
A wide-ranging post from Andrew on the downsides of Google’s AMP solution.
I don’t agree with all the issues he has with the format itself (in my opinion, the fact that AMP pages can’t have
script elements is a feature, not a bug), but I wholeheartedly concur with his concerns about the AMP cache:
It recklessly devalues the URL
Spot on! And as Andrew points out, in this age of fake news, devaluing the URL is a recipe for disaster.
It’s hard to avoid the idea that the primary objective of AMP is really about hosting publisher content inside the Google ecosystem (as is more obviously the objective of Facebook Instant Articles and Apple News).
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.
A cute explanation of different browser caches:
- memory cache,
- service worker cache,
- disk cache, and
- push cache.
This is a fun—and accurate—explanation of service workers.
There’s definitely something “alien” about a service worker—it’s kind of like a virus that gets installed on the user’s device. I’ve taken to describing it as “a man-in-the-middle attack on your own website” which makes sound a bit scarier than is necessary.
This is a really great step-by-step walkthrough of adding a service worker to a website. Mike mentions the gotchas he encountered along the way, and describes how he incrementally levelled up the functionality.
If you’ve been going through a similar process, please write it down and share it like this!
Here’s an interesting use of service workers: figure out the difference (the delta) between the currently-cached version of a file, and the version on the network, and then grab only the bits that have changed. It requires some configuration on the server side (to send back the diff) but it’s an interesting approach that could be worth keeping an eye on.
The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.
This ongoing series about the nuts’n’bolts of implementing Service Workers is really good. This one is great for getting to grips with the cache API.
This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.
The stuff in here about
Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
The battle between web fonts and performance. Ian Feather outlines some possible solutions, but of course, as always, the answer is “it depends”.
A handy one-page cheatsheet for using HTML5’s appcache manifest file for offline storage.
A bookmarklet to help you figure out what files you might want to put in your cache manifest for offline storage.
John has written a very in-depth look at offline storage (using the cache manifest) in HTML5.