I'm interested in this as well, as I haven't dove into service workers.
But I'm still failing to see why you can't pull the local data from local storage and show it, then render the data from the server (should you get new data)?
But I'm still failing to see why you can't pull the local data from local storage and show it, then render the data from the server (should you get new data)?
You can't do anything about your top level index.html file (or the main js and css assets) though. If the user starts offline the second time they use your app, there's no guarantees about those bootup assets being loaded into cache, you'll just get the "you're offline" screen instead.
Since we are talking about hooking the lifecycle of a page, there's no good way to polyfill this with a library. That initial request needs to be serviced, offline, before you can load your polyfill library.
That said I do understand that avoiding this could be desirable.
This is especially useful in non-us, non-eu countries, where people pay a lot for data, relative to their income. Being able to successfully launch and run without any data usage is pretty rad.
Service workers are designed to be run independently of your web page. I.e. Your service worker can run in the background and update your apps resource files (or even cached xhr data) when your website isn't open, so that it's ready when the user accesses your site.
This means your site goes from remotely delivered to locally served. Which reduces the load times to super low.
IMO it's also nice and clean because it lets you completely separate your app and network logic. Your web app itself can be built as if it is always online, and all the offline logic is in the separate code package in a separate thread.
and
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
?
"finally" seems wrong here :)
I'll also note that Safari 10.1 was first with SharedArrayBuffer ;)