I credited the Apple developers with doing a good job in the blog. The problem is Apple's policies end up turning a routine bug fix in to a total nightmare.
[1] https://caniuse.com/?search=CompressionStream
[2] https://gildas-lormeau.github.io/zip.js/api/interfaces/Confi...
As an author you have two main options:
1. Feature detection: check to see if the API exists in the browser, and gracefully fall back if not.
2. UA-sniffing: use the API only on browsers where you've verified that your program works correctly with its implementation.
There's pretty strong consensus on the web that authors should be doing (1), and that (2) is harmful to minority browsers. Every time someone says "the new feature works fine in Firefox if I set my UA to Chrome" they're complaining that the site didn't go with (1).
Yes, using (1) means trusting browsers to get their implementations correct, but they are usually very good about this and getting better. The http://wpt.fyi tests have been a big help here.
0. Wait: Don't adopt the API at all if it is only supported in Chromium, because it's highly probable that the API will have behavioral or API differences if it's implemented by other browsers in the future.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Compression...
If browser vendors are releasing the feature unprefixed, that is their signal that they view the feature as stable. It is the responsibility of the browser vendor to ship unbroken features and use vendor prefixes to unambiguously mark if something isn’t fully baked. It is not the responsibility of developers to stick their finger in the wind and try to divine when a feature has subjectively “reached stability”.
If you ship a bunch of features based on an assumption about how browsers "should" implement an API in the future and it breaks, you can't tell your customers "it's the browser's fault!" Regardless of what's "fair," it's your software that looks broken. So you can navigate that however you want. I choose not to adopt single-vendor APIs for this exact reason.
Indeed you can’t! Which is the core of my argument for why we also need to be able to properly UA-sniff browser versions. If browsers aren’t holding up their end of the stability bargain, they need to give us a way to version-detect and handle the problem on our end.
Right now what’s pissing me off about Safari is that with their left hand they’re delivering buggy implementations of standardized features and with their right hand they’re cutting off our ability to detect which version of their browser we’re running in (and soon, no doubt, whether we’re running in Safari at all).