Hacker News Reader

Comment by pfooti | Hacker News Reader

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.

View on HN

This seems like a very strange API. Why do you need a proxy to intercept network requests coming from your own app?

To serve that requests from local storage if your device or the server is offline.

If the asset is already in local storage, why do you need to create a network request in the first place?

Or why can't this problem be solved with HTTP caching headers and a browser that Does the Right Thing?

I'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.

Just 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.

So HN commenters who don't use Service Workers can have some invective to throw at WebKit.

...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.

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)?

Well, service workers do run in a separate thread which finally brings multithreading (not multi-iframing ;)) to javascript.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

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 ;)

Then 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.

That 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.

Maybe 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.

What 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.

Ah, of course. That is indeed a significant issue...

Service 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.

Can'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.

For web apps running in normal browsers, Service Workers ARE that facade.

You 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.

It'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.

It is yet another hack web developers come up with, as workaround for offline apps.

> 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.

Reply on news.ycombinator.com