Most active commenters

    ←back to thread

    260 points gherkinnn | 16 comments | | HN request time: 0.636s | source | bottom
    1. jonahx ◴[] No.42165501[source]
    Can someone explain what the service worker strategy accomplishes that plain old http Cache headers don't? It saves a (almost zero weight) network roundtrip, but feels like it's re-inventing the entire wheel for that small (I think) optimization? Am I missing something?
    replies(6): >>42165572 #>>42165591 #>>42165649 #>>42165780 #>>42165856 #>>42166137 #
    2. ysofunny ◴[] No.42165572[source]
    that they can be used to compute stuff locally

    I imagine ideally we want user choice of where the computation is happening. if on a mobile device I'd save battery in exchange for network latency

    but in a desktop computer I'd rather do as most local computation as I can

    replies(3): >>42165590 #>>42165735 #>>42165956 #
    3. bathtub365 ◴[] No.42165590[source]
    Radio is one of the biggest users of battery on mobile devices.
    4. ◴[] No.42165591[source]
    5. alganet ◴[] No.42165649[source]
    It was designed for apps, extensions and pages that behave like apps (stuff that might not have a server anywhere, just a manifest and some static HTML/JS). The cache is only one of the use cases.

    I think some pages still use them for running background stuff. My browser is setup to clear all of them upon closing the tab.

    This whole direction is being silently discontinued anyway. Running browser apps has become harder, not easier.

    replies(1): >>42165984 #
    6. jonahx ◴[] No.42165735[source]
    I'm not asking about web workers generally. I'm specifically asking about their use as a client side cache as described in the article.
    7. thfuran ◴[] No.42165780[source]
    A minimal network roundtrip is pretty minor only so long as you're on a reliable connection to a nearby server. Add even a little packet loss or moderate latency jitter and 5,000 miles and suddenly any roundtrip avoided is a good thing.
    8. slibhb ◴[] No.42165856[source]
    You program servive workers in the client whereas headers are controlled by the server. Among other things, this means that service workers work when you have no internet access.
    9. plorkyeran ◴[] No.42165956[source]
    For the sort of thing that are fast enough that network latency is relevant, on a mobile device you save battery by doing them locally. The radio takes more power than the cpu.
    10. imbnwa ◴[] No.42165984[source]
    >This whole direction is being silently discontinued anyway. Running browser apps has become harder, not easier.

    I'm outta the loop, can you expand on how this is the case?

    replies(1): >>42166213 #
    11. EionRobb ◴[] No.42166137[source]
    For a multi-page app, one of the important uses of serviceworkers is pre-loading and caching resources that aren't on the first page. eg you might have a background image that's only displayed three pages deep but can download and cache it as soon as the site is open.

    You can potentially use http2 push to send down files from the server early but I've seen the browser drop the files if they're unneeded for that page load.

    Yes, there are other hacks you could do to make the browser download the resources early, like invisible images or preload audio files, but if you're going down that path why not put in a service worker instead and have it download in the background.

    replies(3): >>42166608 #>>42168719 #>>42169312 #
    12. alganet ◴[] No.42166213{3}[source]
    When these things appeared, both Mozilla and Google were signaling the intention of distributing some kind of standard webapp. At that time, via FirefoxOS and ChromeOS. Even MS was signaling web with Windows 8 (WinJS apps, even for Windows Phone).

    So, there is some piece of infrastructure for this future here and there. Service Workers is one of those pieces. But the apps only achieved some success in closed markets (extension stores). It never became a standard (visit a page, pin it, becomes a fully fledged app).

    Instead, the web moved to mobile and desktop apps through other means (super-Cordoba/Electron-like apps, little JS/HTML insertions in traditional apps, other inventive web ways that do not involve a collaborative standard).

    The leftovers of this imagined distribution mechanism are being pushed aside (hidden in weird menus or options). Tech is still there because it is a standard, but the counterpoint UI and market decisions are pointing in other directions.

    For example, both in Chrome and Firefox, the ability to invoke the browser "chromeless" that was a part of this whole thing has been removed or muted in some way. It was never a standard, so it was removed as soon as possible (probably few people working on it).

    Does that make sense?

    replies(1): >>42185571 #
    13. jeroenhd ◴[] No.42166608[source]
    Unfortunately HTTP/2 push is basically dead. Very few sites made use of it and Chrome removed it: https://developer.chrome.com/blog/removing-push
    14. xnx ◴[] No.42168719[source]
    If preloading is the goal, would hidden/off-screen loading be an option for images?
    15. bastawhiz ◴[] No.42169312[source]
    Preload link tags work great and have been supported for over a decade.
    16. imbnwa ◴[] No.42185571{4}[source]
    Ah, yes, didn't know that service workers belonged to such an larger business plan like that.