Best use case of this I guess, is some kind of flight mode for web apps. Before going in to metro or flight, you click a button, and for example HN caches front page for you.
More than that - service workers have background sync and stuff like that as well. Imagine a messaging app where you can read and write messages no matter what the connectivity state is, then have the phone sync when you come back online.
Exactly. I've written something like that but instead of messaging it was an issue tracker meets wiki. Completely offline with SW and IndexedDB with background sync when there was a connection. Works very well on the airplane :)
Not scary at all. Check out this article on Background Sync [0]. It's not supported everywhere yet but the fallback to sync when the page is open is good enough. Of course you can also do sync on push events (they have broader support) but then you have to show a notification.
Service workers have access to Indexeddb but not to local storage. That's something to remember.
That link describes a web page that keeps running and sending data even after your browser is closed. Why shouldn't I be scared by that? Isn't that the holy grail for anyone who wants to track and surveil users?
It seems like there are some restrictions on them, but they are kind of vague about exactly how restrictive they are.
> Sync events will often complete while the user has a page open to the site, so requiring user permission would be a poor experience. Instead, we’re limiting when syncs can be registered and triggered to prevent abuse. E.g.:
> You can only register for a sync event when the user has a window open to the site.
> The event execution time is capped, so you can’t use them to ping a server every x seconds, mine bitcoins or whatever.
You can still cache the response you just don't get to see what the response was. For those types of resources it's best to only fallback to using them if the user is offline.
