>We addressed this by generating atomic CSS at build time. Atomic CSS has a logarithmic growth curve because it’s proportional to the number of unique style declarations rather than to the number of styles and features we write.
I've always wondered... has anyone checked to see if this strategy of CSS (which AFAICT is slowly growing in popularity, since it's a super simple minification trick) ends up costing more in bandwidth?
It seems like it would, because 1) you frequently need multiple classes per html element, and 2) those html classes need to be sent on every page load, where CSS caches well if used "normally". I can see it being smaller on any individual page, especially with class-name minifying, but across many? And infinite scrolling loading many more elements?
we use this approach since more than a year with very good results. Regarding the data transfer it is not much of a problem because those classes usually get repeated a lot across the elements and having lot of repeated string is the best case scenario for gzip compression leading to basically no size impact.
https://github.com/utilitycss/atomic
This is the framework we developed to create atomic CSS component libraries if you want to have a look (documentation needs some love, but is quite stable)
Your HTML is still undeniably larger than something with dramatically fewer class attributes though, if you minify the same way. Hence my "single page" vs "many" difference.
gzip helps for sure, but I doubt `<class="card">...` ends up larger than `<class="a b c d e"><class="sub-a sub-b q etc"><class="repeat per element">...`.
there is of course a bit of difference in some use cases, my point is that in a real world scenario you often do not have
<class="card"> vs <class="a b c d e">
but more something like
<class="card"><class="stuff-inside-card"><class="other-stuff">
vs
<class="a b c d e"><class="b c f"><class="c d e g">
so in the long run you tend to have more repeated strings across even completely unrelated elements and that usually balances out the possible increase in non gzipped bytes.
But to be honest we did not had a detailed comparison with edge cases and it would be interesting to see when it actually may be a bad idea and when it is totally fine
when you're less "component-y" with your styles, yeah, that happens pretty frequently. careful styling is mostly rare (like all careful things)... but atomic styling seems to make the savings of careful styling effectively impossible, though I absolutely believe it helps the less-careful (especially the least-careful) cases.
I've always wondered... has anyone checked to see if this strategy of CSS (which AFAICT is slowly growing in popularity, since it's a super simple minification trick) ends up costing more in bandwidth?
It seems like it would, because 1) you frequently need multiple classes per html element, and 2) those html classes need to be sent on every page load, where CSS caches well if used "normally". I can see it being smaller on any individual page, especially with class-name minifying, but across many? And infinite scrolling loading many more elements?