You could also drop the hash part and gain most of that improvement. Or module and hash and do better on compression (because the hash is high-entropy).
${local}: 52610 raw, 7927 br. (Now in practice a few of these are likely to need disambiguation, so it’s probably a tad smaller than realistic.)
Frankly I think ${local} is the right target, with global disambiguation where necessary. For typical systems, I consider the hash approach to be foolish: its value is when interacting with unknown other styles, but when you’re compiling everything you should know everything, so you can disambiguate more selectively and succinctly/compressibly, as JS build tools like Rollup do (in flattening modules with colliding names, you’ll get Foo, Foo$1, Foo$2, &c.).
> ${local} is the right target, with global disambiguation where necessary.
How?
---
Another approach is using base52 sequential names, such as `aa, ab, …`. I tried that a few years ago in Webpack, I don't remember but there was an issue, IIRC they weren't deterministic.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.
Here's a comparison using `brotli --best` on my app.
Both, dev and prod, have hashes because that's part of what CSS Modules uses to avoid collisions.
Besides download size, smaller names improve parsing speed too.
Personally I don't think this reduction in size is big enough compared to making all css names unreadable and thus very difficult to debug.
It also makes it much more difficult to create personal browser extensions as all css names are now unreadable.
Use a source map, lots of tools do that for the Js and CSS build process.
You could also drop the hash part and gain most of that improvement. Or module and hash and do better on compression (because the hash is high-entropy).
Rudimentary experiment on https://github.githubassets.com/assets/te.1288ac5c9584fbf2.m... on replacing /(?<module>[A-Za-z0-9_-]+)__(?<local>[A-Za-z0-9_-]+)__(?<hash>[A-Za-z0-9_]{5})\b/:
${module}__${local}__${hash} (original): 72967 raw, 10993 br.
${module}__${local}: 68459 raw, 8867 br.
${hash}: 48754 raw, 8189 br.
${local}: 52610 raw, 7927 br. (Now in practice a few of these are likely to need disambiguation, so it’s probably a tad smaller than realistic.)
Frankly I think ${local} is the right target, with global disambiguation where necessary. For typical systems, I consider the hash approach to be foolish: its value is when interacting with unknown other styles, but when you’re compiling everything you should know everything, so you can disambiguate more selectively and succinctly/compressibly, as JS build tools like Rollup do (in flattening modules with colliding names, you’ll get Foo, Foo$1, Foo$2, &c.).
> ${local} is the right target, with global disambiguation where necessary.
How?
---
Another approach is using base52 sequential names, such as `aa, ab, …`. I tried that a few years ago in Webpack, I don't remember but there was an issue, IIRC they weren't deterministic.
1 reply →
Try zstandard instead of Brotli - a clearly superior format, IMO. Definitely better than gzip.
`zstd --ultra`
This.
The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.