And the same principal that means CSS duplication is compressed away also applies to HTML with a lot of duplicate classes. If you have a lot of components with bg-blue-400 in your markup the same thing will happen when it's served compressed.
Tailwind works when you have a component system on the template/server side. It abstracts away the components so you're not continuously using the same long list of classes throughout the app.
This is true with gzip compression, do you think brotli makes a different with it's dictionary?
Also, wouldn't the purge mean we have changing css files, that cannot be re-used if we generate the css files per page?
We could purge per project, but then we still have more classes then needed, and scanning an entire site would require a lot of deeper integrations to work vs doing it per page.
I don't know a lot about brotli, but I have to imagine every compression algorithm uses tokens to replace reused content, otherwise it wouldn't be effective at all.
The CSS purge is site or app wide, not per page. This is what you want, because the number of unique classes doesn't keep growing and growing as an app gets bigger. A single CSS file then covers the whole app, and is usually much smaller than traditional CSS that has to grow to style more components and patterns throughout an app.
I just checked a few sites using Tailwind in production (not mine), and the CSS build sizes were:
Yeah, the term is utility classes.
And the same principal that means CSS duplication is compressed away also applies to HTML with a lot of duplicate classes. If you have a lot of components with bg-blue-400 in your markup the same thing will happen when it's served compressed.
Tailwind works when you have a component system on the template/server side. It abstracts away the components so you're not continuously using the same long list of classes throughout the app.
This is true with gzip compression, do you think brotli makes a different with it's dictionary?
Also, wouldn't the purge mean we have changing css files, that cannot be re-used if we generate the css files per page?
We could purge per project, but then we still have more classes then needed, and scanning an entire site would require a lot of deeper integrations to work vs doing it per page.
How bad would this be without the purge?
I don't know a lot about brotli, but I have to imagine every compression algorithm uses tokens to replace reused content, otherwise it wouldn't be effective at all.
The CSS purge is site or app wide, not per page. This is what you want, because the number of unique classes doesn't keep growing and growing as an app gets bigger. A single CSS file then covers the whole app, and is usually much smaller than traditional CSS that has to grow to style more components and patterns throughout an app.
I just checked a few sites using Tailwind in production (not mine), and the CSS build sizes were:
Nice, thank you for taking the time to get these numbers. :)