4 ms·
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 s
by lilbobbytables 9y ago
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)?
- donjoe 9y agoWell, service workers do run in a separate thread which finally brings multithreading (not multi-iframing ;)) to javascript.
- jfbastien 9y agohttps://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer 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 ;)
- egeozcan 9y agoThen you have to build that in your application. In typical use-cases, your application does not have to know about Service Workers, but usually not the vice versa. For example, you can decide to intercept /article/show/{id}, just get the content for the article from your API, compile it with a template you have cached, and serve that instead. From the perspective of your app, nothing has changed. It is the holy grail of progressive enhancement.
- pfooti 9y agoThat works fine for your xhr data (and is what I do now), but is idiosyncratic to your library (note that detecting online state, responding to online state changes, etc all add complexity to this seemingly simple module, as does managing cache expiry). 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.
- mercer 9y agoMaybe I'm confused, but provided I bootstrap the app every time by downloading a script that then downloads the big-ass app (that includes styling and whatnot) if necessary, I should be fine right? Or am I missing something? That said I do understand that avoiding this could be desirable.
- pfooti 9y agoWhat happens if your user is offline (airplane mode, no data, etc), and can't download the initial bootstrap script? There's no way to avoid an error page at this time, unless you use a browser-specific plugin (the drive offline addon is one of these, but they now use service workers for the same functionality on chrome IIRC). 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.
- mercer 9y agoAh, of course. That is indeed a significant issue...
- MuppetMaster42 9y agoService workers are in a separate layer to your app code. They're in another thread, they're subject to different memory/storage rules, they have access to a few extra apis IIRC. 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.
- deleted 9y ago[deleted]