This is a smart way to queue up POST submissions for later if the user is offline. It’s not as powerful as background sync (because it requires the user to revisit your site) but it’s a good fallback for browsers that support service workers but don’t yet support background sync
Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:
- the “app shell” model is not the only—or even the best—way of building a progressive web app, and
- always, always, always render from the server first.
I’ve never been so excited by a single diff in a JSON file.
Service workers are coming to Safari.
The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
Tell it, brother!
A great collection of learned lessons from implementing service workers.
I really, really like it when people share their own personal experiences and “gotchas!” like this.
If you use the ProcessWire Content Management System, Johannes has written a handy plug-in that allows you to specify which files should be cached by a service worker.
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!
Got questions about the security of service workers? This document probably has the answer.
Ethan has added a service worker to his site and he’s got a nifty little recipe for showing a list of saved-for-offline articles.
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.
If your company is or is planning on doing business in emerging markets, architecting your web applications for performance through progressive enhancements is one easy way to drastically improve accessibility, retention, and user experience.
This article uses “progressive enhancement” and “progressive web app” interchangeably, which would be true in an ideal world. This is the first of a three part series, and it sounds like it will indeed document how to take an existing site and enhance it into a progressive web app—a strategy I much prefer to creating a separate silo that only works for a subset of devices (the app-shell model being pushed by Google).
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.
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.
This is really good fun! And thanks to service workers, it works offline too.
The rounds are:
- Dead or Not Dead,
- Number 1 or Not Number 1, and
- Oscar or Not Oscar.
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