7 ms·
With service workers you can transparently intercept outgoing XHRs and replace their results with cached values. You can even do a cache race if you want (cance
by pfooti 9y ago
With service workers you can transparently intercept outgoing XHRs and replace their results with cached values. You can even do a cache race if you want (cancel the xhr if your cache returns first). This is a hugely important feature for making web apps work offline-first. I mean, it's also a big part of progressive web apps, which is the next thing I'm going to complain about. (I don't personally care much about webrtc, but I can see why people do care about it).
The general point isn't about any one feature in particular. It is about a history safari has with not implementing (or half-heartedly implementing, as with indexeddb for so long) APIs that are important to making the web a useful platform.
Reasonable people can disagree whether or not those features are good, but it seems basically true that my mobile web work is constrained by what iOS safari outright refuses to do, more than anything else.
- millstone 9y agoThis seems like a very strange API. Why do you need a proxy to intercept network requests coming from your own app?
- reitanqild 9y agoTo serve that requests from local storage if your device or the server is offline.
- millstone 9y agoIf the asset is already in local storage, why do you need to create a network request in the first place?
- zachrose 9y agoOr why can't this problem be solved with HTTP caching headers and a browser that Does the Right Thing?
- cormacrelf 9y agoI'm pretty sure HTTP caching headers don't provide a guarantee that they will be stored for any length of time at all, the browser is free to empty it at will. They also don't guarantee that all your cached assets will be valid with respect to each other (ie your browser might cache an HTML file but not the content it refers to). Most importantly, though, you can't simply disable HTTP caching when you notice that you're back online. Those cache entries are there now, and they're hard to get out. Service Workers, on the other hand, will just transparently stop intercepting stuff. With respect to localStorage, I think the idea is that you absolutely can do almost an entire offline mode with it, with the caveat that your content (html, js, css, images) won't get stored there, so you can't load the page at all! Also I think there are considerations about how difficult it is for many front end architectures to implement this transparent fallback themselves. If you're a Redux or ClojureScript type of programmer it might be utterly obvious and even trivial to implement (just add a simple middleware), but sadly not everyone is, and a lot of the offline logic would have to be implemented everywhere in your codebase. A service worker lets you do it all in one place. It's a toss-up whether to use localStorage or a service worker if you could viably do either. Blanket logic over all your HTTP calls would be easier in a service worker, and more customized logic would be easier in localStorage, I'm guessing.
- cormacrelf 9y agoJust to articulate the difference on HTTP caching again: Using HTTP caching for saying how long online clients should keep a value becomes impossible if you want to tell browsers to store things forever in offline mode. HTTP caching makes no distinction between whether you're online or offline.
- xenadu02 9y agoSo HN commenters who don't use Service Workers can have some invective to throw at WebKit.
- donjoe 9y ago...since you don't know whether there is a new version available on the server or not. To not make the user wait, you show him/her the - potentially - outdated version of your data until a new version is available. It's especially useful in situations where users lack internet connection.
- lilbobbytables 9y agoI'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 ago
- Sacho 9y agoCan't this be solved by a library? It seems like you could easily build a facade in front of requests that queried local storage...you would just need to figure out whether the device/server is online or not.
- floatboth 9y agoFor web apps running in normal browsers, Service Workers ARE that facade.
- underwater 9y agoYou need to be able to bootstrap the page to start with. If I request news.ycombinator.com and I'm offline, then Service Workers are the only way to avoid an error page.
- marksomnian 9y agoIt's not just XHRs, it's all requests by your app. The HTML, the CSS, images, everything. The entire site can be served offline by this API.
- pjmlp 9y agoIt is yet another hack web developers come up with, as workaround for offline apps.
- pier25 9y ago> my mobile web work is constrained by what iOS safari outright refuses to do You are privileged to be able to work with Safari. Imagine if you had to work with its bastard deformed brothers WKWebView and UIWebView.