4 ms·

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

by millstone 9y ago

zachrose 9y ago
Or why can't this problem be solved with HTTP caching headers and a browser that Does the Right Thing?
- cormacrelf 9y ago
  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.
  - cormacrelf 9y ago
    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.
- xenadu02 9y ago
  So 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 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 ago
    Well, service workers do run in a separate thread which finally brings multithreading (not multi-iframing ;)) to javascript.
    - jfbastien 9y ago
      https://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 ago
    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.
  - pfooti 9y ago

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

zachrose 9y ago

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

cormacrelf 9y ago
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.
- cormacrelf 9y ago
  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.
xenadu02 9y ago
So 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 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 ago
  Well, service workers do run in a separate thread which finally brings multithreading (not multi-iframing ;)) to javascript.
  - jfbastien 9y ago
    https://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 ago
  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.
- pfooti 9y ago