Why I Hated It
I'd spent years getting good at CSS architecture. BEM methodology. Structured component stylesheets. Separation of concerns between markup and style. Tailwind felt like it threw all of that away. Utility classes in the HTML felt like going backwards.
The second problem: I judged it by reading HTML instead of writing it. Tailwind HTML looks chaotic to read but it's actually fast to write — the editor autocomplete, the eliminated context-switching, the co-location of style and structure. You have to write it to feel the workflow.
What Changed My Mind
A greenfield project where I used Tailwind for everything. Two weeks in, I noticed I hadn't opened a separate CSS file once. Every style decision was visible in the component. Changing the component meant changing one file. The cognitive overhead of mentally mapping class names to CSS properties faded as the utility names became fluent.
The design system constraint is what I'd missed. Tailwind's spacing scale, color palette, and type scale create consistent decisions by default. You can't accidentally use spacing-23px if spacing-23px isn't in your scale.
Key takeaways
- Write Tailwind for a week on a real project before forming an opinion — the workflow advantage doesn't appear when reading code, only when writing it
- Tailwind's design scale (spacing, colors, typography) is a feature, not a limitation — consistent decisions by default reduces the bikeshedding that slows CSS architecture decisions
- Extract repetitive patterns into components rather than @apply directives — the composition model (reusable components) is cleaner than CSS abstraction for most UI patterns
Conclusion
I was wrong about Tailwind, and I'm glad I gave it a fair shot instead of writing it off. The workflow isn't for everyone and that's fine — but it deserves to be evaluated by using it, not by reading someone else's HTML.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
