The class list gets ugly. We don't mind.
Technology
Tailwind puts every style decision in the markup, and the standard objection is correct: a div with fourteen classes is hard to read, and it looks like the framework fighting you at 2am. We build with it anyway, because the alternative, a separate stylesheet, forces you to hold two files in your head to know what an element actually looks like.
It is the single most used piece of our stack after the frameworks themselves. It shows up on nearly every project regardless of what CMS or backend sits behind it, because it composes the same way whether the page is server rendered, static, or exported from a design tool.
Why
The tradeoff, stated honestly
- The objection is real, not overblown
A component with a dozen utility classes is not pretty. If you are used to semantic class names and a stylesheet you can read top to bottom, Tailwind markup looks like noise, and the first reaction from anyone new to it is usually right: this is harder to read at a glance.
- Colocation beats a file you have to hold in your head
The tradeoff is that the style lives right next to the element it styles, so nothing is one file away from where it applies. Once more than one person touches a codebase, that beats a stylesheet where a rule three thousand lines away silently wins the cascade.
- It composes the same way everywhere we ship
Server rendered pages, static exports, a design tool's code export: the same utility classes work in all of them. We do not maintain a separate design language per rendering strategy, which matters once a project has more than one framework in it.
