3 ms·

It doesn't matter if it's been available for 10 years on Chrome—if it's not reliable on other platforms, don't use it. And you absolutely CAN and should detect

It doesn't matter if it's been available for 10 years on Chrome—if it's not reliable on other platforms, don't use it. And you absolutely CAN and should detect implementation bugs in the API. At the very least you can throw CompressionStream's entire compression/decompression process behind a try…catch block, and fall back to the older method on an error.

gildas 4y ago
It was hard for me to anticipate that Apple would implement the CompressionStream API incorrectly 6 months later. However, it is extremely likely that an exception was indeed raised when this bug was triggered. I was never made aware of the existence of this bug. Besides, zip.js does its best to rely on fallback implementations in case of errors. I'm not supposed to integrate the entire CompressionStream API test suite (and all the other APIs) into zip.js either.
jefftk 4y ago
> It doesn't matter if it's been available for 10 years on Chrome—if it's not reliable on other platforms, don't use it. 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 http://wpt.fyi tests have been a big help here.
- turnsout 4y ago
  I don't disagree with any of that, but you have another option: 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.
  - gildas 4y ago
    Please read the documentation of the API and you might think the probability would be very low [1]. Note also that zip.js works totally fine in all stable browsers, Safari 16.4 included. There are no known issues [2]. I have absolutely no idea what we are talking about because it looks like the bug has been fixed by Apple in the stable version of Safari. And maybe zip.js helped them to do so. [1] https://developer.mozilla.org/en-US/docs/Web/API/Compression_Streams_API https://developer.mozilla.org/en-US/docs/Web/API/Compression... [2] https://github.com/gildas-lormeau/zip.js/issues https://github.com/gildas-lormeau/zip.js/issues
  - AshleysBrain 4y ago
    Waiting doesn't work when Apple do things like ship a working and spec-compliant WebAssembly API which works great so you start using it, then they completely break it in a subsequent update, and leave it both enabled and broken for months. No amount of foresight or caution will save you in that case. It's ultimately the browser maker's responsibility to make sure APIs work.
  - Uehreka 4y ago
    Chromium-based browsers make up a large portion of many people’s marketshare. It absolutely makes sense to use APIs that are available in them and then polyfill the feature with “the old way” if you feature-detect that it isn’t there. 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”.
    - turnsout 4y ago
      Actually, the developer's primary responsibility is to deliver working software to their client or customer. 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.
- duped 4y ago
  Option 3: Allow dependents to enable it explicitly with a feature flag.
  - gildas 4y ago
    Options 1 and 3 are implemented.

gildas 4y ago

It was hard for me to anticipate that Apple would implement the CompressionStream API incorrectly 6 months later. However, it is extremely likely that an exception was indeed raised when this bug was triggered. I was never made aware of the existence of this bug. Besides, zip.js does its best to rely on fallback implementations in case of errors. I'm not supposed to integrate the entire CompressionStream API test suite (and all the other APIs) into zip.js either.

jefftk 4y ago

> It doesn't matter if it's been available for 10 years on Chrome—if it's not reliable on other platforms, don't use it. 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 http://wpt.fyi tests have been a big help here.

turnsout 4y ago
I don't disagree with any of that, but you have another option: 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.
- gildas 4y ago
  Please read the documentation of the API and you might think the probability would be very low [1]. Note also that zip.js works totally fine in all stable browsers, Safari 16.4 included. There are no known issues [2]. I have absolutely no idea what we are talking about because it looks like the bug has been fixed by Apple in the stable version of Safari. And maybe zip.js helped them to do so. [1] https://developer.mozilla.org/en-US/docs/Web/API/Compression_Streams_API https://developer.mozilla.org/en-US/docs/Web/API/Compression... [2] https://github.com/gildas-lormeau/zip.js/issues https://github.com/gildas-lormeau/zip.js/issues
- AshleysBrain 4y ago
  Waiting doesn't work when Apple do things like ship a working and spec-compliant WebAssembly API which works great so you start using it, then they completely break it in a subsequent update, and leave it both enabled and broken for months. No amount of foresight or caution will save you in that case. It's ultimately the browser maker's responsibility to make sure APIs work.
- Uehreka 4y ago
  Chromium-based browsers make up a large portion of many people’s marketshare. It absolutely makes sense to use APIs that are available in them and then polyfill the feature with “the old way” if you feature-detect that it isn’t there. 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”.
  - turnsout 4y ago
    Actually, the developer's primary responsibility is to deliver working software to their client or customer. 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.
duped 4y ago
Option 3: Allow dependents to enable it explicitly with a feature flag.
- gildas 4y ago
  Options 1 and 3 are implemented.