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.
A wonderfully thoughtful piece from Robin, ranging from the printing technologies of the 15th century right up to the latest web technologies. It’s got all my favourite things in there: typography, digital preservation, and service workers. Marvellous!
Behind the amusing banter there’s some really solid performance advice in here. Good stuff.
Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.
Jason talks through the service worker strategy for his company website.
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.
Jake goes into the details of what exactly is happening when a service worker is installed or replaced.
This is easily the most complex part of working with service workers, and I think I’m beginning to wrap my head around it, but the good news is that, for the most part, you don’t really need to know the ins and outs of this to get started (and dev tools are now making it easier to nuke from orbit if this begins to bite).
This is a truly fantastic example of progressive enhancement applied to a form.
What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.
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!
A nice introduction to progressive web apps. There’s a little bit of confusion about permissions—whether a site has been added to the home screen or not has no effect on the permissions granted to it (for things like push notifications)—but the wrap-up nails the advantages of using the web:
No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.
Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.
This one is definitely for service worker nerds only. I’ve been trying to get my head around this idea of “foreign fetch” which allows third parties to install service workers—could be handy for sites with APIs like Huffduffer and The Session. This article does a good job of explaining the somewhat tangled process.
Alex runs through the features that a progressive web app must have, should have, and would be nice to have.
In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.
Right now, this is in the nice-to-have category:
Mobile-friendly, not mobile-only.
Personally, I’d put that in the must-have category, and not just for progressive web apps.
Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.
Lyza put together some example code for her Smashing Conference talk on service workers. If you haven’t written a service worker before, these are really nice examples of how to grok it bit by bit.
This is a really good overview of progressive web apps:
An ideal web app is a web page that has the best aspects of both the web and native apps. It should be fast and quick to interact with, fit the device’s viewport, remain usable offline and be able to have an icon on the home screen.
At the same time, it must not sacrifice the things that make the web great, such as the ability to link deep into the app and to use URLs to enable sharing of content. Like the web, it should work well across platforms and not focus solely on mobile. It should behave just as well on a desktop computer as in other form factors, lest we risk having another era of unresponsive m.example.com websites.
Some interesting interface ideas here for informing users when a service worker is doing its magic.
In the future users may expect a site to work offline after visiting again, but until this happens, I think it is a good idea to let the users know about this feature.
The devs at The Guardian walk through the process of building a progressive web app for the Olympics. There were some gotchas with the life cycle of service workers, but the pay-off was worth it:
Once you get there though, it’s quite magical when you load the page on a phone, switch it to airplane mode, reload, and continue using the app as though nothing was wrong.
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.
Some helpful “gotchas” that could save you some frustration if you’re starting out with service workers.
If you’re going to dip your toes into the world of service workers, this handy library from the Chrome team is a good place to start.
Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:
We’re considering allowing the browser to run multiple concurrent instances of a service worker.