5 ms·

The demo also demonstrates why something like this is insufficient: you can’t rely on the service worker loading. Service workers must be optional. There’s a re

The demo also demonstrates why something like this is insufficient: you can’t rely on the service worker loading. Service workers must be optional. There’s a reason invocations always start by checking if navigator.serviceWorker even exists, and why navigator.serviceWorker.register() returns a Promise, and why the ServiceWorkerRegistration type is comparatively complicated: service workers aren’t permitted in all contexts, and even when they are, they’re installed asynchronously in the background after the page finishes loading. To show this easily, try this in a Firefox Private Browsing window: service workers are disabled there, so the request goes through to the server, which responds 405 Method Not Allowed. So in order to make this approach reliable, you’ll need to run that code on your server, not just in the service worker. This is totally viable, but an approach that has seen surprisingly little experimentation. (I myself have a grand scheme that’s actually fairly fleshed out, but I’ve only touched it once in the last year and a half, so don’t hold your breath. My scheme is predicated upon aggressively not requiring client-side scripting, but using it only for completely optional enhancement; and upon running the same source code in a worker, in a service worker, at the edge or on the origin server, with only a teeny bit of JavaScript on the main thread.)

cash22 4y ago
What contexts are they not permitted? I know that not all browsers support them, but are there other limitations?
- chrismorgan 4y ago
  One particularly interesting context here is that force reloading deliberately bypasses service workers. Try pressing Shift+F5 or Ctrl+Shift+R, and all of a sudden the button stops working until you do a regular, non-forced reload. Beyond that, I don’t know, but I would expect things like some lower-powered and -storaged devices rejecting service workers, and maybe privacy modes too, though in that case they could possibly be allowed with just background stuff neutered.
  - jhugo 4y ago
    Given that the spec requires Service Workers to be optional, future Web specs & implementations may build upon that requirement, so writing your software to assume they always load is both brittle today and subject to unexpected breakage in future.
    - chrismorgan 4y ago
      De jure they’re optional, but if they are implemented everywhere or close enough to everywhere, they will de facto become mandatory, as has happened many times before. This is a large part of the reason why a large part of me wishes browsers wouldn’t provide service workers in Private Browsing/Incognito/whatever modes.
      - panzerboiler 4y ago
        I really don't understand your point. Since ServiceWorkers provide an offline experience and can be inspected from the client, they should be better than no ServiceWorker with respect to privacy.
        chrismorgan 4y ago
        The main purposes of service workers are offline support and persistent background stuff. These are typically irrelevant in Private Browsing windows, which are designed for short-term use, and so service workers are almost always pure waste. (Not always, but almost always, and in line with the intended purpose and semantics of Private Browsing windows, though you can certainly use it in somewhat different ways.) It’s similar to a large part of the reason why Local Storage and Indexed DB were historically disabled in Private Browsing: why store stuff when it’s only going to be deleted immediately? Browsers have mostly headed in the direction of removing distinguishing features from their Private Browsing modes, partly to thwart detection of that mode, and partly because many things started to carelessly depend on the gated functionality. Firefox still doesn’t allow writing to Indexed DB (and only made Local Storage work far later than Chromium), and I’ve definitely encountered sites that just assumed it would work, and so fell over in early initialisation. And so for this specific subthread: it’s ossification at work. If something is supposed to be able to change but never actually changes, you find when you try to change it that you can’t do so any more because people have built too much stuff that assumed it wouldn’t change.
thagsimmons 4y ago
This is too negative - it's fine to require service workers if it's justified. Service workers work in private browsing mode in Safari, Chrome and Brave, and is only unimplemented in Firefox because it "hasn't been a priority yet": https://bugzilla.mozilla.org/show_bug.cgi?id=1320796 https://bugzilla.mozilla.org/show_bug.cgi?id=1320796 Firefox will eventually catch up. The possibilities for this approach are actually quite interesting, and go far beyond the much less useful scheme you outlined that relegates it strictly to just being an optimization.
- chrismorgan 4y ago
  I used Firefox’s Private Browsing purely as an easy way of demonstrating the problem. A forced reload (e.g. Ctrl+Shift+R) is another way of showing it, and one that’s defined in the spec. I’ll tweak my statement slightly: for regular site functionality, service workers must be optional. Depending on service workers for anything that does not inherently require them (like background sync or receiving push messages) is bad.
  - eyelidlessness 4y ago
    > Depending on service workers for anything that does not inherently require them (like background sync or receiving push messages) is bad. Or access to CacheStorage, and acting as an offline server when the network is unavailable. Perfectly reasonable to depend on if your use case requires it.
  - thagsimmons 4y ago
    Again, this is much too sweeping and categorical. The forced reload problem with service workers is well known and easy to work around. The Firefox private browsing example is neither here nor there - an implementation weakness that has no good rationale and will eventually go away. If your functionality justifies it, you should feel free to use and depend on service workers. If service workers are not present, you should feel free to display an error explaining it to the user. Many things we commonly depend on are optional in corner cases, but that doesn't hold us back.
nabakin 4y ago
I'm more optimistic about using Service Workers in this way, but I agree this was definitely not their intended use case so there will be problems. There's another flaw I see with using Service Workers in this way. After a period of time where the Service Worker is inactive (a minute or so on Firefox), the browser will shutdown the Service Worker. When it shuts down, all variables in the Service Worker scope are freed and I assume the WebAssembly server instance as well. How would you maintain server state, in this scenario?
- madsbuch 4y ago
  Commit to a browser persistent storage or skip it off to a server.
  - nabakin 4y ago
    That's what I'm thinking too. There's no way to keep the state in Rust which means constantly updating a browser persistent storage through JS or keeping state client side in the tab's environment. A pretty janky workaround
- nymanjon 4y ago
  I pretty much build my personal offline-first web apps this way, but with JS. https://news.ycombinator.com/item?id=33319875 https://news.ycombinator.com/item?id=33319875
  - nabakin 4y ago
    Cool! If I'm reading your code correctly, you store service worker state in the cache?
    - nymanjon 4y ago
      Yeah, I store everything in IndexedDB using a simple Key-Value abstraction library. I have a cache where I store any temporary state between pages.
koonsolo 4y ago
Firefox is running behind on a lot of the latest features. And considering their market share, sometimes it's just less effort to ignore its limitations.
buro9 4y ago
I RTFA first and couldn't get it working, came here and saw your comment and now know why it doesn't work. I may be a minority weirdo, but I have set dom.serviceWorkers.enabled to false. Why? Because legit sites aren't broken by this and I always clear all browsers cache and databases on close (several times per day). IMHO service workers are used mostly for long-lived tracking, to supercede the cookie, and I also dislike background processing for things I just don't care about. So for me... service workers are disabled. They just don't work. And it turns out the web works just fine.
- yunohn 4y ago
  You read the article titled “… Service Workers…” and tried getting it working on a device, that you explicitly disabled Service Workers because of your strong opinion on them? I’m… not sure what to say.
nymanjon 4y ago
I've created an offline-first web app which is based on service workers. I've created another one that could be pushed to the back end (like on Node.js) that would be just a straight MPA app. I guess both of them could be pushed to the back end if needed. Since I just use them for myself I don't worry about them not working without JS enabled. But I created HTMF, similar to HTMX but made to be a progressive enhancement from the get-go. https://github.com/jon49/Soccer https://github.com/jon49/Soccer https://github.com/jon49/WeightTracker https://github.com/jon49/WeightTracker https://github.com/jon49/MealPlanner https://github.com/jon49/MealPlanner https://github.com/jon49/htmf https://github.com/jon49/htmf

cash22 4y ago

What contexts are they not permitted? I know that not all browsers support them, but are there other limitations?

chrismorgan 4y ago
One particularly interesting context here is that force reloading deliberately bypasses service workers. Try pressing Shift+F5 or Ctrl+Shift+R, and all of a sudden the button stops working until you do a regular, non-forced reload. Beyond that, I don’t know, but I would expect things like some lower-powered and -storaged devices rejecting service workers, and maybe privacy modes too, though in that case they could possibly be allowed with just background stuff neutered.
- jhugo 4y ago
  Given that the spec requires Service Workers to be optional, future Web specs & implementations may build upon that requirement, so writing your software to assume they always load is both brittle today and subject to unexpected breakage in future.
  - chrismorgan 4y ago
    De jure they’re optional, but if they are implemented everywhere or close enough to everywhere, they will de facto become mandatory, as has happened many times before. This is a large part of the reason why a large part of me wishes browsers wouldn’t provide service workers in Private Browsing/Incognito/whatever modes.
    - panzerboiler 4y ago
      I really don't understand your point. Since ServiceWorkers provide an offline experience and can be inspected from the client, they should be better than no ServiceWorker with respect to privacy.
      - chrismorgan 4y ago
        The main purposes of service workers are offline support and persistent background stuff. These are typically irrelevant in Private Browsing windows, which are designed for short-term use, and so service workers are almost always pure waste. (Not always, but almost always, and in line with the intended purpose and semantics of Private Browsing windows, though you can certainly use it in somewhat different ways.) It’s similar to a large part of the reason why Local Storage and Indexed DB were historically disabled in Private Browsing: why store stuff when it’s only going to be deleted immediately? Browsers have mostly headed in the direction of removing distinguishing features from their Private Browsing modes, partly to thwart detection of that mode, and partly because many things started to carelessly depend on the gated functionality. Firefox still doesn’t allow writing to Indexed DB (and only made Local Storage work far later than Chromium), and I’ve definitely encountered sites that just assumed it would work, and so fell over in early initialisation. And so for this specific subthread: it’s ossification at work. If something is supposed to be able to change but never actually changes, you find when you try to change it that you can’t do so any more because people have built too much stuff that assumed it wouldn’t change.

thagsimmons 4y ago

This is too negative - it's fine to require service workers if it's justified. Service workers work in private browsing mode in Safari, Chrome and Brave, and is only unimplemented in Firefox because it "hasn't been a priority yet": https://bugzilla.mozilla.org/show_bug.cgi?id=1320796 https://bugzilla.mozilla.org/show_bug.cgi?id=1320796 Firefox will eventually catch up. The possibilities for this approach are actually quite interesting, and go far beyond the much less useful scheme you outlined that relegates it strictly to just being an optimization.

chrismorgan 4y ago
I used Firefox’s Private Browsing purely as an easy way of demonstrating the problem. A forced reload (e.g. Ctrl+Shift+R) is another way of showing it, and one that’s defined in the spec. I’ll tweak my statement slightly: for regular site functionality, service workers must be optional. Depending on service workers for anything that does not inherently require them (like background sync or receiving push messages) is bad.
- eyelidlessness 4y ago
  > Depending on service workers for anything that does not inherently require them (like background sync or receiving push messages) is bad. Or access to CacheStorage, and acting as an offline server when the network is unavailable. Perfectly reasonable to depend on if your use case requires it.
- thagsimmons 4y ago
  Again, this is much too sweeping and categorical. The forced reload problem with service workers is well known and easy to work around. The Firefox private browsing example is neither here nor there - an implementation weakness that has no good rationale and will eventually go away. If your functionality justifies it, you should feel free to use and depend on service workers. If service workers are not present, you should feel free to display an error explaining it to the user. Many things we commonly depend on are optional in corner cases, but that doesn't hold us back.

nabakin 4y ago

I'm more optimistic about using Service Workers in this way, but I agree this was definitely not their intended use case so there will be problems. There's another flaw I see with using Service Workers in this way. After a period of time where the Service Worker is inactive (a minute or so on Firefox), the browser will shutdown the Service Worker. When it shuts down, all variables in the Service Worker scope are freed and I assume the WebAssembly server instance as well. How would you maintain server state, in this scenario?

madsbuch 4y ago
Commit to a browser persistent storage or skip it off to a server.
- nabakin 4y ago
  That's what I'm thinking too. There's no way to keep the state in Rust which means constantly updating a browser persistent storage through JS or keeping state client side in the tab's environment. A pretty janky workaround
nymanjon 4y ago
I pretty much build my personal offline-first web apps this way, but with JS. https://news.ycombinator.com/item?id=33319875 https://news.ycombinator.com/item?id=33319875
- nabakin 4y ago
  Cool! If I'm reading your code correctly, you store service worker state in the cache?
  - nymanjon 4y ago
    Yeah, I store everything in IndexedDB using a simple Key-Value abstraction library. I have a cache where I store any temporary state between pages.

koonsolo 4y ago

Firefox is running behind on a lot of the latest features. And considering their market share, sometimes it's just less effort to ignore its limitations.

buro9 4y ago

I RTFA first and couldn't get it working, came here and saw your comment and now know why it doesn't work. I may be a minority weirdo, but I have set dom.serviceWorkers.enabled to false. Why? Because legit sites aren't broken by this and I always clear all browsers cache and databases on close (several times per day). IMHO service workers are used mostly for long-lived tracking, to supercede the cookie, and I also dislike background processing for things I just don't care about. So for me... service workers are disabled. They just don't work. And it turns out the web works just fine.

yunohn 4y ago
You read the article titled “… Service Workers…” and tried getting it working on a device, that you explicitly disabled Service Workers because of your strong opinion on them? I’m… not sure what to say.

nymanjon 4y ago

I've created an offline-first web app which is based on service workers. I've created another one that could be pushed to the back end (like on Node.js) that would be just a straight MPA app. I guess both of them could be pushed to the back end if needed. Since I just use them for myself I don't worry about them not working without JS enabled. But I created HTMF, similar to HTMX but made to be a progressive enhancement from the get-go. https://github.com/jon49/Soccer https://github.com/jon49/Soccer https://github.com/jon49/WeightTracker https://github.com/jon49/WeightTracker https://github.com/jon49/MealPlanner https://github.com/jon49/MealPlanner https://github.com/jon49/htmf https://github.com/jon49/htmf