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.
Remember when I wrote about using push without notifications? Sebastiaan has written up the details of the experiment he conducted at Indie Web Camp Berlin.
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.
Crazy clever!
I love this example of paying it forward:
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.
Service Workers have such huge potential power, and I feel like we (developers on the web) have barely scratched the surface with what’s possible.
Needless to say, I couldn’t agree more!
Trys is thinking through some of the implicatons of service workers, like how we refresh stale content, and how we deal with slow networks—something that’s actually more of a challenge than dealing with no network connection at all.
There’s some good food for thought here.
I’m so excited to see how we can use Service Workers to improve the web.
A step-by-step walkthrough of a really useful service worker pattern: allowing users to save articles for offline reading at the click of a button (kind of like adding the functionality of Instapaper or Pocket to your own site).
I had a great time chatting with Lea and Emily about service workers on this episode of their podcast—they’re such great hosts!
Here’s the huffduffed audio.
This is such a lovely, lovely review from Marc!
Jeremy’s way of writing certainly helps, as a specialised or technical book on a topic like Service Workers, could certainly be one, that bores you to death with dry written explanations. But Jeremy has a friendly, fresh and entertaining way of writing books. Sometimes I caught myself with a grin on my face…
I strongly recommend that you read Going Offline by Jeremy Keith. Before his book, I found the concept of service workers quite daunting and convinced myself that it’s one of those things that I’ll have to set aside a big chunk of time to learn. I got through Jeremy’s book in a few hours and felt confident and inspired. This is because he’s very good at explaining concepts in a friendly, concise manner.
Very valuable observations from Paul on his travels, talking to developers and business people about progressive web apps—there’s some confusion out there.
My personal feeling is that everyone is really hung up on the A in PWA: ‘App’. It’s the success and failure of the branding of the concept; ‘App’ is in the name, ‘App’ is in the conscious of many users and businesses and so the associations are quite clear.
This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.
Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.
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.
Smart thinking—similar to this post from last year—about using the navigator.connection API from a service worker to serve up bandwidth-appropriate images.
This is giving me some ideas for my own site.
Here’s the first part of a chat I had on Friends Talk Frontend about Resilient Web Design and Going Offline.
I remember Jason telling me about this weird service worker caching behaviour a little while back. This piece is a great bit of sleuthing in tracking down the root causes of this strange issue, followed up with a sensible solution.