2 ms·
This is a novel take that I think genuinely adds something to tired tailwind discourse: > I think the most important factor in Tailwind's success is that it do
by wwweston 1y ago
This is a novel take that I think genuinely adds something to tired tailwind discourse:
> I think the most important factor in Tailwind's success is that it does one thing very correctly: it demands the developer who installs it set up a config file that lays out all codebase-wide style constants: colors, margin sizes, fonts, border radii, etc. Writing individual styles that do not use a pre-configured constant from the config file is clunky in Tailwind. This is a good thing, an unironic win for Tailwind. More than anything else, this is what a large codebase with multiple frontend devs needs: a rigid set of global constants that everyone is strongly incentivized to use.
I’m still considering its merits, but it at least goes beyond the “How I learned to stop worrying and embrace tailwind’s standardized soup” vs “I can’t stand this, it goes against every organizing principle I’ve found useful” familiar dichotomy.
- roguecoder 1y agoIt is also a great example of where worse is better, when it leads people to doing work they always needed to do.
- treyd 1y agoBut this isn't unique or new with Tailwind. SCSS and that family of tools had this 10 years ago.
- wwweston 1y agoI think the SCSS and SASS implementations I used 5-10 years back had the capability but didn’t require any set variables, and I think one point of the argument is that this has more benefits than you’d think.