iuioiua
commented
1 month ago To reiterate, I suggested std/streams just so there are no blockers to getting the ball rolling with an implementation. I think such an implementation should exist in std/compress (or similar). However, more discussion is needed before committing to a whole new package.
Bouncing off of what was briefly discussed on discord, I'm opening this issue to discuss the possibility of having the Brotli compression algorithm (RFC7932) added somewhere to Deno's STD. I would like to have a go at implementing the algorithm myself, but would also like feedback on the idea from everyone else.
I think Brotli would be a good addition to the STD as it's a widely supported compression format supported by almost all browsers under the Accept-Encoding header and would allow people to easily compress their content without additional tooling. Brotli is also supposedly faster than Gzip, although I doubt a pure JavaScript implementation of Brotli would beat the built in implementation of Gzip, but would still be beneficial for when serving static content as that can all be pre-brotli-ed.
The default suggested location for such an addition to be introduced was under
@std/streams, although this doesn't seem like a good fit in practicality as the contents of@std/streamsis more focused towards utility streams. On a side note, there also seems to be quite an inconsistency about whether a file format get's its own module named after itself (csv,toml,yaml) or if it gets placed under its type of category (archive/tar).