Wrapping Up: What We Built & What Comes Next 🎓

March 5, 20263 min read
service workerPWAofflinecachingweb workersprogressive web appsbackground sync

Where We Started vs. Where We Ended

We started with a fragile website. Any hiccup — spotty Wi-Fi, a server blip, a flight with no internet — and the user gets a blank white screen. No explanation. No fallback. Just gone.

We ended with a site that:

  1. Detects and communicates connectivity status to the user proactively
  2. Caches every page and asset the user has visited, serving them offline
  3. Proactively pre-caches content in the background before it's even requested
  4. Routes every request intelligently — network first, cache first, or synthetic response depending on the resource type
  5. Handles authentication offline — login, logout, and protected pages all behave sensibly without a connection
  6. Saves unsent form data to IndexedDB so nothing is lost if the connection drops mid-draft

One Thing We Didn't Cover (But Could Have)

Request timeouts — if a server is slow rather than down, the user still waits. The safeRequest helper could be extended with a timeout:

js

// If the server takes more than 3-4 seconds, serve from cache instead Promise.race([ fetch(request.url, fetchOptions), new Promise((_, reject) => setTimeout(() => reject('timeout'), 3500)) ])

Slow networks are just as painful as dead ones. Worth adding to a production service worker.

The Bigger Point

"Service workers are great for progressive web applications — but they're really great for making all websites behave better. A more intuitive and empathetic experience for the user."

This wasn't a course about building installable apps. It was about raising the baseline quality of any website. The default behaviour of the web is fragile. Service workers are how you fix that.

Resources Kyle Recommends

  • serviceworke.rs — recipes with annotated code for every common SW pattern (and the reason Kyle knows half of what he knows about service workers)
  • Jeremy Keith's "Going Offline" — the book that first got Kyle thinking about service workers for plain websites
  • Workbox — Google's higher-level SW framework if you want less boilerplate and are okay with less control

My Takeaways from the Whole Course

Looking back across every section:

  1. Web workers — offload CPU-heavy work off the main thread, keep the UI responsive
  2. Service workers — the programmable browser proxy that makes offline possible
  3. The Cache API — developer-controlled storage, paired with the fetch handler
  4. Two-way messaging — how the page and SW stay in sync on status the SW can't see itself
  5. Versioned caches — atomic updates, clean old cache deletion on activation
  6. The fetch handler — respondWith, routing logic, three resource strategies
  7. Auth-aware routing — mimicking server logic offline using isLoggedIn + isOnline
  8. safeRequest() — a configurable helper that eliminates routing repetition
  9. Background caching — slow, polite, fire-and-forget pre-caching of content
  10. IndexedDB for form persistence — saving user input across tab closes and connectivity failures

"Whatever I did here is not the only way to do it. I just wanted to show you that we have the control in a service worker to do whatever is best for the user."

Go install a service worker on your own website. 🚀

Back to Wrapping Up