compression
compression copied to clipboard
whatwg
Include brotli
It would be good to support all the compression, or at least decompression, schemes supported by servers and browsers. This looks like a great step forward to not having to write compression and decompression in javascript.
My use-case would be to download a bunch of brotli files in an archive (somewhat like tar), split them into individual files (unarchive, but don't decompress yet) in the service-worker cache, and return them to the browser as called for.
Mentioned in https://github.com/WICG/compression/blob/master/explainer.md#future-work
This needs to be higher up in the priorities.
In my case, I need to download a large binary/json data file and Brotli's compression offers significant savings compared to Zopfli. I cannot use a CDN because the file is either too large or the CDN's on-the-go compression is not suitable for the file.
Also, Brotli is already included in most browsers as a part of H2.
@prajaybasu As far as I know, browsers are only shipping the decompression dictionary. Brotli has a separate dictionary needed for compression, which would significantly increase the size of the browser.
It's possible to add Brotli only to DecompressionStream and not to CompressionStream, but I feel it would be confusing.
So currently I am adopting a wait-and-see approach.
It will be more confusing to realize that one browser supported decompression algorithm is not available, and have to locate a Javascript decompressor for it, and figure out how to use it, to work around the fact that it isn't built in. Especially when it is the best compression for the type of data being sent from the server.
@ricea Deno would be interested in a brotli option for DecompressionStream and CompressionStream. Even if it is not immediately standardized due to browser pushback, could we at least agree to the label that brotli will use? That way an addition in Deno will not be incompatible with a future browser implementation.
The two real contenders for brotli would be br and brotli I think. The former matches the value brotli has in content-encoding, but the latter is clearer to novices.
I've been matching the content-encoding header as a rule, so I'm inclined to choose br. Maybe we could have brotli as an alias? I'm not sure how I feel about that.
IIRC, Brotli has a number of customisable settings which we would ultimately want to expose through the API, but as with DEFLATE we can add them later.
Sounds good. I'll throw up a tentative spec PR so we have something a little more formal.
Both Node.js and Cloudflare Workers would also be interested in a brotli option for these. Looking forward to the spec PR.
This would be great. I currently maintain brotli.js, a JavaScript-based brotli decompressor. Personally, I use it to decode WOFF2 fonts as part of fontkit, but it is very widely used (1.8M downloads per week on npm) by many others as well. It works well, but it is quite heavy in terms of JS payload size of the library itself, so it would be much better if I could use the native brotli decoders built into browsers instead.
Browser-wise it is better to add it as a native library wrapper, as it is done for gzip. This way, its footprint will be nearly zero - decoder library is already linked into browser. For pure JS decoder (to enable polyfills) we also have java-to-js-transpiled decoder. For encoder - well, it would be nice to have native library; if not - I agree, WASM is a viable option.
I discussed with some colleagues (who also work on WebKit), and we generally support the idea of adding Brotli to the Compression spec.
I am decompressing some files using DecompressionStream and being able to decompress brotli would save a lot of space. The browser already decodes Content-Encoding: br compression, so it should be possible to also expose this decoder in DecompressionStream.
