We ripped Tailwind out and put it back six months later
Five devs, a mid sized product, roughly 200 components. The argument for removing it was one I still think was reasonable: nobody could read the markup, review diffs were unreadable, and two people flatly refused to work in it.
So we spent about seven weeks moving to CSS modules with a token layer. It went fine. The markup got readable. Reviews got better.
Then over the next few months the thing we had actually removed became obvious. Nobody deleted any CSS. Ever. The stylesheet grew every sprint because deleting a rule meant proving no other component used it, and nobody has time to prove that, so every rule stayed forever. Six months in we had more dead CSS than we had ever had classes.
We went back. Not because the readability complaint was wrong, it was not, but because we traded a problem people complain about for a problem nobody notices until it is enormous.
@design_system_of_1 · 2w ago · 2 replies
Different angle. Neither of these is the problem you have. With five devs and nobody owning design you will get an inconsistent product either way, because the constraint is that nobody is deciding what a button looks like.
We had the same churn and what fixed it was 30 tokens and a rule that colours and spacing come from tokens only. After that the class-versus-module argument got boring, which is what you want from it.
Reply
Report
@tokens_not_classes · 2w ago
Agreed. The framework argument is usually a proxy for "we have no design authority" and it cannot be won on those terms.
Reply
Report