The part about decoder size is what really resonates. In constrained environments like ComputerCraft (or embedded systems), you're often not just picking the best compression ratio — you're picking the algorithm whose total footprint (compressed data + decompressor code) is smallest.

bzip2's BWT approach benefits from having no heuristics to encode, no lookup tables for offsets, no Huffman table metadata beyond the one coding table. The article's estimate of ~1.5KB for a single-table bzip2 decoder is plausible; I've seen similar results with stripped-down Huffman coders.

The point about zopfli is underappreciated too. People compare gzip vs bzip2 speed without noticing that 'fast gzip' and 'optimal gzip' are very different things. At comparable ratio targets, bzip2 is actually competitive.

Early on the article mentions that xz have zstd have gotten more popular than bzip, and my admitted naive understanding is that they're considered to have better tradeoffs in teems of collision compression time and overall space saved by compression. The performance section heavily discusses encoding performance of gzip and bzip, but unless I'm missing something, the only references to xz or zstd in that section are briefly handwaving about the decoding times probably being similar.

My impression is that this article has a lot of technical insight into how bzip compares to gzip, but it fails actually account for the real cause of the diminished popularity of bzip in favor of the non-gzip alternatives that it admits are the more popular choices in recent years.

This seems as good a thread as any to mention that the gzhttp package in klauspost/compress for Go now supports zstd on both server handlers and client transports. Strangely this was added in a patch version instead of a minor version despite both expanding the API surface and changing default behavior.

https://github.com/klauspost/compress/releases/tag/v1.18.4

Notice that bzip3 has close to nothing to do with bzip2. It is a different BWT implementation with a different entropy codec, from a different author (as noted in the GitHub description "better and stronger spiritual successor to BZip2").

imho: the future is a specialized compressor optimized for your specific format. ( https://openzl.org/ , ... )

bzip2 is the compression algorithm equivalent of that one coworker who does incredible work but nobody ever talks about. meanwhile gzip gets all the credit because it's "good enough"

Just use zstd unless you absolutely need to save a tiny bit more space. bzip2 and xz are extremely slow to compress.

PPMd (of 7-Zip) would beat BZip2 for compressing plain text data.