Hacker News Reader

Comment by thagsimmons | Hacker News Reader

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

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.

View on HN

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.

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.

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

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.

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.

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

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

it's fine to require service workers if it's justified

I don't agree with this because you're essentially defending writing websites and apps for specific browsers. "Oh, this doesn't work in your browser because it requires [specific tech|devs to test in more than one browser|whatever]" is a lame excuse in a world where progressive enhancement has been an accepted approach to developing web software for twenty years.

As a tech demo to show something is possible it's fair enough, but in the real world this shouldn't ever happen.

In this example where Firefox is the outlier, if you write your web app differently than you otherwise would have then you'd be writing websites and apps for a specific browser...

Cool demo. Like with any PWA, it would be just very gret if all that stuff would be really progressive. Run in the browser for the 90% and render real HTML (that might even work with CSS) for the rest. IMHO frameworks that fallback to accessible HTML for server rendering in a deterministic fashion would be awesome. I personally find the argument that ist works for most not very ethically sustainable...

Reply on news.ycombinator.com