IIRC, in a recent thread about zstd, someone claimed brotli was faster. Perhaps one needs to look at whether the sample being compressed is web stuff.

If you’re too busy to check yourself, the “squash compression benchmark” page has results for dozens of codecs and different inputs.

Brotli is not just for Web stuff.

Brotli is heavily tuned for "web stuff". It's literally got a built-in dictionary full of commonly used HTML fragments:

https://gist.github.com/klauspost/2900d5ba6f9b65d69c8e

Shoot me, works well for the average desktop (=Electron) application then.

Electron is just web stuff.

Sure but it actually benchmarks well broadly maybe despite its heavy web optimizations.

Sure. In theory. But every other response to this comment are clearly talking about web stuff, and in practice brotli is really only used for web stuff.

I don't know what's theoretical about it. There are Debian packages for brotli and it just behaves like a stdio codec, same as the `xz` command.

Brotli has a static dictionary heavily geared towards web formats, and there really is no reason to use brotli outside of web stuff: the point of brotli is that it has browser support and does 15~20% better than gzip.

It's not bad per-se, but if you're not constrained to the web zstd will have a better compression ratio at every throughput (and better throughput at every compression ratio), and if you want maximum compression period it's not close to competing with LZMA-based formats (xz, lzip).

I think he mean is less popular (like zstandard and lz4) compared to zlib and LZMA and BZip2. this is unfortunate because Brotli and Zstandard compress much better than zLib and LZ4 and decompress much faster than zlib lzma and LZ4

I’m using the phrase “in theory” colloquially, which means something like “sure, you could technically use it that way, but nobody really does/it’s very rare”.