Comment 15 for bug 1706107

I'm curious about the choice of UpUp instead of using Workbox (https://workboxjs.org/). Workbox development is led by Google--along with Mozilla, one of the main proponents of service workers--and is the more modular successor to the sw-helper and sw-precache libraries that I based my work on for my session at the Evergreen 2017 conference.

UpUp, by comparison, appears to be a single-person project and I've had no success finding a list of projects that use it or any real community around it, which potentially leaves our project exposed to the whims of a single dev. Compare the stats at https://www.npmjs.com/package/upup vs. https://www.npmjs.com/package/workbox-sw

Another concern is that this branch bundles the two minified UpUp JS files + license--but don't we generally prefer using npm to bundling these days (particularly for minified assets)? Both Workbox and UpUp are available via npm; with Workbox, the service worker would be generated at build time based on the routing config (similar to what's defined in UpUp's config).

Another concern is that UpUp is being given the entire service-worker scope, but is very limited in what kinds of different offline strategies it can support; for example, Workbox runtime caching supports both network-first and cache-first strategies (https://workboxjs.org/examples/workbox-runtime-caching/index.html), and also supports per-file cache invalidation, whereas UpUp appears to implement only a cache-first strategy and invalidates the entire set of cached files based only on the cache-version parameter (daily based on this branch). These sorts of limitations will impact what we can do with service workers for other parts of Evergreen.