You might not need… a service worker
15 points by rslabbert
15 points by rslabbert
Interesting article.
Fwiw, when they say that Mux's rewriting of a client's m3u8 playlist could have easily been done server-side instead of using service workers, I agree...
But the article they reference specifically said:
Mux’s own player has built-in rendition filtering, and all fixes they tried didn’t work: fork the player, run a server-side proxy that rewrites manifests per customer, or tell the customer no.
We've done all of the above in the past at Swarmify Video, and they work just fine, so I suspect this was a technical solution to a social problem: having one weird customer (probably some unique network setup).
Funny that the first mentions in the article were “an overeager engineer very familiar with new web tech thought they were helping by doing an offline cache, and instead made the website harder to update.”
Exactly my experience with service workers at $WORK 😬.
The web was doing just fine when it was just forms dagnabbit!
That asset fingerprinting is still a problem today came as a surprise to me.
Every place I've worked in the past 15 years had it solved quite well, with approximately half a day of dev time.
Web developers seem super quick to reach for service workers these days and I don't get it. Their primary purpose in a lot of web apps seems to be to cause issues. Whenever a site just refuses to load data or whatever, the solution in 50% of cases is to delete the service worker and let the web app re-add it (though browsers don't make this trivial).
The solution in the other 50% of cases is to switch to Chrome or some other browser that's more lax about CORS than Firefox.
The solution in the other 50% of cases is to switch to Chrome or some other browser that's more lax about CORS than Firefox.
As far as I am aware the various browsers agree about what the requirements for CORS are.
Other reasons things fail are tracking scripts: both Firefox and Safari detect and block the kinds of loads that make it possible to track.
Regardless, the general gist of your argument is that "if it works in chrome the other browsers are wrong and they should just switch to chrome or a chrome wrapper". Seriously if web page is broken in Safari and Firefox, you're IE6-ing your site.
You have to implement it exactly right and right everytime.
I worked on an offline app (school cafeteria's have terrible wifi but a lot of transactions) that really benefited from offline mode with local storage.
The service worker api is not great. Google's wrapper (workbox) is slightly better.