4 ms·

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.

turnsout 4y ago
I think the larger issue is that you're relying on new or exotic browser APIs without enough skepticism about their behavior across a range of platforms. CompressionStream is brand new in 16.4, so zip.js should absolutely NOT assume it's available, and if it does detect the API, it should gracefully fall back to the older implementation if it encounters errors. I realize this is not your issue, but a dependency—but it could be a reason to use a library with a less aggressive upgrade philosophy, such as Pako.
- gildas 4y ago
  Author of zip.js here, the CompressionStream API is available for 3 years in Chromium-based browsers [1]. That's why I integrated it 6 months ago in zip.js. However zip.js can detect if the API is present or not, and can work if not available (e.g. in Firefox). It cannot detect implementation bugs in the API though. Note that there's also an option to disable the use of the API [2]. [1] https://caniuse.com/?search=CompressionStream https://caniuse.com/?search=CompressionStream [2] https://gildas-lormeau.github.io/zip.js/api/interfaces/Configuration.html#useCompressionStream https://gildas-lormeau.github.io/zip.js/api/interfaces/Confi...
  - turnsout 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. 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
  Browser makers always recommend feature detection (i.e. use a feature if it's available) over hacks like user-agent sniffing to selectively enable features. Web developers can't look in to a crystal ball and pre-emptively code around APIs with unexpected issues.
  - turnsout 4y ago
    But you can avoid adopting APIs that have been Chrome-only until 5 minutes ago…
    - AshleysBrain 4y ago
      That means avoiding features that can enhance your software, improve performance, and help get ahead of competitors.
      - turnsout 4y ago
        Yeah, that's one of the many tradeoffs in developing a web app. It has not changed since the Netscape days.

turnsout 4y ago

I think the larger issue is that you're relying on new or exotic browser APIs without enough skepticism about their behavior across a range of platforms. CompressionStream is brand new in 16.4, so zip.js should absolutely NOT assume it's available, and if it does detect the API, it should gracefully fall back to the older implementation if it encounters errors. I realize this is not your issue, but a dependency—but it could be a reason to use a library with a less aggressive upgrade philosophy, such as Pako.

gildas 4y ago
Author of zip.js here, the CompressionStream API is available for 3 years in Chromium-based browsers [1]. That's why I integrated it 6 months ago in zip.js. However zip.js can detect if the API is present or not, and can work if not available (e.g. in Firefox). It cannot detect implementation bugs in the API though. Note that there's also an option to disable the use of the API [2]. [1] https://caniuse.com/?search=CompressionStream https://caniuse.com/?search=CompressionStream [2] https://gildas-lormeau.github.io/zip.js/api/interfaces/Configuration.html#useCompressionStream https://gildas-lormeau.github.io/zip.js/api/interfaces/Confi...
- turnsout 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. 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
Browser makers always recommend feature detection (i.e. use a feature if it's available) over hacks like user-agent sniffing to selectively enable features. Web developers can't look in to a crystal ball and pre-emptively code around APIs with unexpected issues.
- turnsout 4y ago
  But you can avoid adopting APIs that have been Chrome-only until 5 minutes ago…
  - AshleysBrain 4y ago
    That means avoiding features that can enhance your software, improve performance, and help get ahead of competitors.
    - turnsout 4y ago
      Yeah, that's one of the many tradeoffs in developing a web app. It has not changed since the Netscape days.