PWA Caching: Why I'm skeptical of standard Service Workers

Standard PWAs let the browser play god with the application lifecycle. Most devs just accept this, but if you actually look at how service workers handle activation and storage, it's a mess of race conditions and "waiting" states that make version control a nightmare.

I've been digging into Spirit, and it takes a completely different approach: the application owns the installation, not the browser. The core shift here is treating spirit-sw.js as firmware rather than middleware. Instead of acting as a proxy that intercepts requests to check a cache, it acts as a bootloader. It serves a hardcoded bootstrap string that pulls the app from IndexedDB.

The Spirit Architecture

This isn't your typical "cache-first" strategy. It's an IDB-native system split into four parts:

• spirit-grave.js: The storage layer. It handles burying files as Blobs in IndexedDB and exhuming them later.
• spirit-reg.js: The installer. It reads a spirit-manifest.json and shoves everything into IndexedDB under gnoke:spirit/files during the first visit.
• spirit-sw.js: The bootloader. It doesn't touch Cache Storage. It returns a bootstrap string that reconstructs the app—CSS is injected, images become blob URLs, and JS runs in manifest order. Zero network requests on boot.
• spirit-revive.js: The updater. You manually call Spirit.reviveFromNetwork(). No background magic; the app decides when to update.

Lifecycle: Standard PWA vs. Spirit

The difference in the AI workflow of the app's loading sequence is stark:

Standard PWA:

Request URL → SW intercepts → Cache check → Serve or Fetch → Background update check → Wait for tabs to close → Potential mid-session code swap

Spirit:

Request URL → SW returns bootstrap → Bootstrap reads IndexedDB → App reconstructed locally → App runs (offline/online) → Update only via manual trigger

My Take

The biggest win here is determinism. In a standard PWA, you're always gambling on whether the browser has decided to activate the new service worker or if you're stuck in a "waiting" state. Spirit eliminates the "mixed-version" state where some assets are new and some are old.

By treating the service worker as stable firmware that rarely changes, the actual application logic can be updated as a single managed operation. It's a much cleaner deployment model for anyone who actually cares about state consistency.