The service worker spec was carefully and deliberately designed to give the browser, not the site, control over resource consumption. The browser is allowed to stop any service worker at almost any time. See https://github.com/w3c/ServiceWorker/blob/master/implementat...

Is there UX work to be done? Sure. But the fundamental problem is that they fill a need that is not met at all by Apple, and not even in a silly "use metal instead of vulkan because reasons" kind of NIH but we'll support some other similar standard fashion, but in a "nope" way.

So, kudos for the speedy es6. I'm still not going to tell people to use safari on macos, and I'm still going to build crazy DIY caches for safari on iOS because I can't do stuff with service workers in a standardized way.

What exactly are you supposing a service worker would be doing? They can't do huge downloads (the worker is shut down when there are no pages using it and it can only be reactivated by another browsing session or push message), can't receive push messages without showing a notification... there really is very little a service worker can do nefariously.

It can, however, help improve battery life by allowing you to better control the offline experience, and not needlessly activate cell radios.

How does your grandmother check if the website she visits isn't doing something nefarious without service workers? Does she run the CPU profiler to see all the JS being executed? That's pretty badass, I wish my grandmother was this cool.