I am amazed at the variety of repos shared - by you, as well as others. Thanks!
Repo links:
https://github.com/facebook/zstd
https://github.com/google/brotli
https://github.com/ClickHouse/ClickHouse
https://github.com/evanw/esbuild
https://github.com/figma
https://github.com/tailwindlabs/tailwindcss
https://github.com/caddyserver/caddy
https://github.com/haproxy/haproxy
https://github.com/uNetworking/uWebSockets
In Ask HN: What are the best publicly available FAMANG code repos?google
brotli
TypeScript2015–2026
google / brotli
brotli
Brotli compression format
35Distinct people
39Mentions
0Explicit recommenders
15.1KGitHub stars
What to know before exploring
What it is
Brotli compression format
GitHub
Where it is used
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- dropbox/rust-brotli · linked in 2 of the same discussions
- google/gipfeli · linked in 2 of the same discussions
- meta/zstd · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year39 dated mentions
Observed mentions: 2015-05-26 11:50:27 UTC to 2026-10-26 00:43:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 3 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 6 | 0 | 6 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Introduction
Brotli is a generic-purpose lossless compression algorithm that compresses data
using a combination of a modern variant of the LZ77 algorithm, Huffman coding
and 2nd order context modeling, with a compression ratio comparable to the best
currently available general-purpose compression methods. It is similar in speed
with deflate but offers more dense compression.
The specification of the Brotli Compressed Data Format is defined in
RFC 7932.
Brotli is open-sourced under the MIT License, see the LICENSE file.
Please note: brotli is a "stream" format; it does not contain
meta-information, like checksums or uncompressed data length. It is possible
to modify "raw" ranges of the compressed stream and the decoder will not
notice that.
Installation
In most Linux distributions, installing brotli is just a matter of using
the package management system. For example in Debian-based distributions:
apt install brotli will install brotli. On MacOS, you can use
Homebrew: brew install brotli.
Of course you can also build brotli from sources.
Build instructions
Vcpkg
You can download and install brotli using the
vcpkg dependency manager:
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install brotli
The brotli port in vcpkg is kept up to date by Microsoft team members and
community contributors. If the version is out of date, please create an issue
or pull request on the vcpkg repository.
Bazel
See Bazel
CMake
The basic commands to build and install brotli are:
$ mkdir out && cd out
$ cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=./installed ..
$ cmake --build . --config Release --target install
You can use other CMake configuration.
Python
To install the latest release of the Python module, run the following:
$ pip install brotli
To install the tip-of-the-tree version, run:
$ pip install --upgrade git+https://github.com/google/brotli
See the Python readme for more details on installing
from source, development, and testing.
Contributing
We glad to answer/library related questions in
brotli mailing list.
Regular issues / feature requests should be reported in
issue tracker.
For reporting vulnerability please read SECURITY.
For contributing changes please read CONTRIBUTING.
Benchmarks
Squash Compression Benchmark / Unstable Squash Compression Benchmark
Large Text Compression Benchmark
Lzturbo Benchmark
Related projects
Disclaimer: Brotli authors take no responsibility for the third party projects mentioned in this section.
Independent decoder implementation
by Mark Adler, based entirely on format specification.
JavaScript port of brotli decoder.
Could be used directly via npm install brotli
Hand ported decoder / encoder
in haxe by Dominik Homberger.
Output source code: JavaScript, PHP, Python, Java and C#
7Zip plugin
Dart compression framework with
fast FFI-based Brotli implementation
with ready-to-use prebuilt binaries for Win/Linux/Mac
Read the full README on GitHubWhat Hacker News says
3 sourcesStatic dictionary is not why Brotli reaches excellent compression density. Much of it comes from the more advanced context modeling and in general more dynamic entropy modeling.
Brotli wins over Zstd on web compression even when you fill the static dictionary with zeros.
No Mountain View based engineers participated in the development of Brotli, it was built in Zurich. The static dictionary was distilled from a language corpus originally having 40 languages. To reduce the binary size while keeping effectiveness, I reduced it to six: English, Spanish, Chinese, Russian, Hindi, Arabic. What got into the dictionary and in which order it was (both words and transforms) were chosen by how much entropy they reduced in a relatively large test corpus including diverse material (for example over 110 natural languages).
Brotli was originally designe
Read the rest
d as a faster to decode replacement of LZMA for fonts to enable WOFF2. LZMA was too slow for that use. WOFF2 is just geometry, no natural languages there. There, W3C observed that Brotli performed similarly to LZMA in density but was significantly (~5x) faster to decode -- and enabled the WOFF2 launch.
Unlike SDCH, Brotli's performance does not degrade when the static dictionary ages. This is because Brotli only uses invalid LZ77 commands to codify static dictionary entries. If you don't use them, you are not paying for them. Just like Zstd, users can bring their own dictionaries when they prefer that -- a functionality that was in Brotli before it was introduced in Zstd.
Unlike ZStd, Brotli degrades less for exotic languages heavy on utf-8 (Korean, Vietnamese, Chinese, Japanese, etc.), and especially so for mixed data such as HTML-commands mixed with the above utf-8 sources.
Unlike LZMA, Brotli's context modeling works for very short data, too -- It becomes about 0.6 % worse on gigabyte corpora, but can be 15+ % better on shortest documents.
Unlike Zstd, Brotli offers the data in a streamable order, i.e., hides less data during the transfer. The user can decode much more out of a brotli stream than a respective fraction of zstd stream (shadowed amount is in tens of bits vs. tens of kilobytes in zstd). This is because brotli does not reshuffle the data within the blocks for less cpu-work at decoding time. Any shadowing of data will make other dependant resources loads start later or dependant processing (Javascript or HTML parsing) to happen later.
Most of Brotli's advances come from other algorithms than LZ77. The LZ77 part of ZStd and Brotli are essentially the same. The LZ77 algorithm is proven optimal when the data is infinitely long as well as the sliding window -- this means that the longer the data, the less difference you see. If you benchmark Brotli vs. Zstd with real life data (like HTML pages of 75 kB) you see a different performance behaviour than if you compare them using a 100 MB or 10 GB file. There, most of Brotli's benefits disappear.
In a gigabyte multi-corpus comparison, Brotli still compresses ~5 % more than Zstd. See: https://github.com/google/brotli/issues/642 -- aggregated here: https://encode.su/threads/2947-large-window-brotli-results-a...
Zstd's encoder has seen more work during the years and some features (like the long maching) is missing from Brotli. Reaching parity in the encoder could reduce the gap. An interesting option would be to have a single encoder for both.
Compiling is also difficult: One continual topic has been performance degradations when moving from GCC/CLANG to MSVC. Brotli was never optimized for MSVC and it seems something is going badly wrong there. Also, in the past several benchmarks were comparing a non-optimized build of Brotli vs a release build of Zstd. This was because until summer 2020 Brotli compiled without options produced a non-optimized build -- you'd need to configure release specifically to get it right.
It's also impossible to identify whether an arbitrary file is compressed with brotli. It lacks a magic number.
https://github.com/google/brotli/issues/298
In Zstandard v1.5.0