Here’s the opening keynote I gave at Frontend United in Utrecht a few weeks back.
Less than 24 hours after I put the call out for a solution to this gnarly service worker challenge, Trys has come up with a solution.
Offline fallback page with service worker - Modern Web Development: Tales of a Developer Advocate by Paul Kinlan
Paul describes a fairly straightforward service worker recipe: a custom offline page for failed requests.
I love the way that Benjamin is documenting his activities at Homebrew Website Club Brighton each week:
Another highly productive 90 mins.
Homebrew website club is on every Thursday evening 6.00-7.30pm at Clearleft. You should come along!
Two of my favourite things: indie web and service workers.
This makes me so happy. I remember saying when my book came out, that the best feedback I could possibly get would be readers making their websites work offline. The same can be said for the talk of the book.
This is a really clever technique from Scott that he unveiled at An Event Apart in Seattle. It uses a header sent by a service worker to distinguish between returning and new visitors—much neater than relying on a cookie. I’ve updated my service worker on The Session to use this technique now.
Here’s a thorough blow-by-blow account of the workshop I ran in Nottingham last week:
Jeremy’s workshop was a fascinating insight into resilience and how to approach a web project with ubiquity and consistency in mind from both a design and development point of view.
A small but perfectly formed progressive web app. It’s a private, offline-first personal journal with no log-in and no server-stored data. You can read about the tech stack behind it:
Your notes are only stored on your device — they’re never sent to a server. You don’t even need to sign-in to use it! It works offline, so you can reflect upon your day on the slow train journey home.
An interesting proposal from Jake on a different way of defining how service worker fetch events could be handled under various conditions. For now, I have no particular opinion on it. I’m going to let this stew in my mind for a while.
This is the real challenge for service workers:
For 30 years, we taught billions of humans that you need to be connected to the internet to consume the web via a browser! This means web users need to unlearn that web sites can’t be used offline.
I’m going to have to read through this article by Jake a few times before I begin to wrap my head around this background fetch thing, but it looks like it would be perfect for something like the dConstruct Audio Archive, where fairly large files can be saved for offline listening.
A five-part video series from Ire on how she built the “save for offline” functionality on her site.
The first one is about getting a set set up on Ghost so you can probably safely skip that one and go straight to the second video to get down to the nitty-gritty of the Cache API and service workers.
They let me write a 24 Ways article again. Will they never learn?
This one’s a whirlwind tour of using a service worker to provide a custom offline page, in the style of Going Offline.
By the way, just for the record, I initially rejected this article’s title out of concern that injecting a Cliff Richard song into people’s brains was cruel and unusual punishment. I was overruled.
A great primer by Ire:
Web workers, service workers, and worklets are all scripts that run on a separate thread. So what are the differences between these three types of workers?
Imagine a PWA podcast app that works offline and silently receives and caches new podcasts. Sweet. Now we need a permissions model that allows for silent notifications.
This just blew my mind! A fiendishly clever pattern that allows you to inline resources (like critical CSS) and cache that same content for later retrieval by a service worker.
I love this example of paying it forward: