Tetris in your browser. Visit it once and it works offline (if your browser supports service workers) so go ahead and add it to your home screen.
Send messages when you’re back online with Service Workers and Background Sync – Twilio Cloud Communications Blog
This example of using background sync looks like it’s specific to Twilio, but the breakdown of steps is broad enough to apply to many situations:
On the page we need to:
- Register a Service Worker
- Intercept the “submit” event for our message form
- Place the message details into IndexedDB, an in browser database
- Register the Service Worker to receive a “sync” event
Then, in the Service Worker we need to:
- Listen for sync events
- When a sync event is received, retrieve the messages from IndexedDB
- For each message, send a request to our server to send the message
- If the message is sent successfully, then remove the message from IndexedDB
And that’s it.
A useful tool to help you generate a manifest file, icons, and a service worker for your progressive web
A nice straightforward account of building and testing a progressive web a… I mean, website.
I think every website from now on should use some of the Progressive Web App features. It’s even confusing to call it “Apps” as it applies to all websites and apps.
A practical guide to Progressive Web Apps for organisations who don’t know anything about Progressive Web Apps : Records Sound the Same
Sally gives a really good introduction to using service workers as a progressive enhancement.
A great little script from Una that’s perfect for blogs and news sites—allowing users to explicitly save a page for offline reading.
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.