First-Party Support for modern Streams API
lucsoft opened this issue · comments
Currently, it's kinda hard to work with fflate and the modern Stream API together.
Already many Browsers have support for it.
Ideas:
Work together with the CompressionStream API
Provide Transformers that can make a ZIP Stream from Streamed Files (and the other way around too)
Unfortunately because this library aims to support IE11 with no polyfills and no bloat, I can't add support for the Stream API directly. However it's actually not that difficult to use fflate with streams, you can take a look at the stream adapter and at the Modern Buildless guide for some examples. I could write more guides on using fflate with streams, or finally write that modern wrapper for fflate with the modern Stream API, direct Promise support, etc.
CompressionStream performance has been improving lately, maybe this library can use it by default if it's available and fallback to the JS implementation, but at the moment CompressionStream is only a few percent faster than fflate so it's probably not worth it (besides, it's Chromium-specific). If you really want though you can install a custom ZIP handler for DEFLATE (type 8) using CompressionStream and zip.add(new YourCustomCompressorUsingCompressionStream('filename.txt')).
Let me know if you have any other suggestions.
I would like to see a use of native Compression/Decompression Stream used by the built in tools directly instead for a even smaller/faster bundle.
IE11 is pretty dead already in my opinion.
Also, both Deno and NodeJS have (De)CompressionStream built in now also.
there should rather be a polyfill for a (De)CompressionStream out there instead.
I don't see why an abandoned/outdated browser target need up to date packages.
IE11 Users (if they even exists) could use an outdated version of fflate.
And yes as you wrote it is possible to turn modern JavaScript to IE11 with babel and all the other transformers.
To be clear, I agree that IE11 is very dead. The issue is that at this point, fflate has such large consumers that breaking ES5 would definitely be a major version change, something I don't know how long will take given that I want v1 to be feature-complete. I'm currently spending my OSS time mostly on Parcel but I'll revisit this in a few weeks and try to work on an update.