I tried to love TailwindCSS, here's why I couldn't | Balazs Barta ∙ Design Technologist

Scroll through tech Twitter or GitHub, and you’ll see developers praising its utility-first approach. But as someone who’s spent years crafting maintainable CSS systems, I see a concerning pattern: we’re returning to practices we fought hard to move away from. … **The difference is striking.** The traditional approach tells you exactly what this element is - a primary button. The Tailwind version? It fundamentally uses inline styles disguised as classes. We’ve replaced `style="background-color: blue"` with `bg-blue-700`, but the fundamental problem remains: we’re mixing content with presentation. … ## The real cost of utility-first CSS The problems with Tailwind become apparent when your project grows. Want to change how all your primary buttons look? With traditional CSS, it’s one change in your stylesheet. With Tailwind, you’re hunting through your entire codebase, replacing dozens of utility combinations. And what happens when design requirements change? Imagine updating the padding on all your cards from `p-4` to `p-6`. With traditional CSS, it’s a single line change. With Tailwind, it’s a search-and-replace operation that could easily miss edge cases or break other components. … ## The maintenance nightmare Advocates of Tailwind often argue that it eliminates the need to think about naming conventions. But names serve a purpose - they convey meaning. When I see `.card`, I know what it represents. When I see `p-4 rounded-lg shadow-md`, I have to mentally parse multiple style definitions just to understand what I’m looking at. **This cognitive overhead becomes a real problem in larger teams and projects.** New developers need to learn not just what components exist, but memorize combinations of utility classes that create those components.