[chrismorgan]

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.

[thagsimmons]

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.

[skybrian]

I think a better way to say it is that, for ordinary, general purpose websites, it's unlikely that such a complicated architecture would be in any way superior to a regular web page implemented using a more ordinary architecture, and there are downsides.

But that doesn't rule it out in some special case. Special cases are special. (I recently wrote a Chrome-only web app because it requires access to the serial port.)

[thagsimmons]

I don't think this is significantly different from what I said ("if your functionality justifies it..."). That is, evaluate service workers in the same way that you would any other complicated additional requirement or feature.

[chrismorgan]

I’m curious how you mean to work around the forced reload problem, because the way I’m looking at it, it’s impossible to work around, by design.

I say: feel free to use service workers, but do not feel free to depend on service workers. They must be optional in general-purpose websites.

[thagsimmons]

Very few things are impossible to work around. In this case, you can detect that the service worker is no longer controlling the page, and do something about it: re-register the worker, soft reload the page, etc. I've also seen people do dodgier things like trying to intercept hard reloads, but that's not necessary.

At any rate, this is more of a StackOverflow question than an HN question, and the details of what works will differ from project to project.

https://stackoverflow.com/questions/51597231/register-servic...

[eyelidlessness]

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