Why I switched to Tailwind
Utility-first CSS frameworks often face skepticism, but the productivity gains are undeniable once you get past the initial learning curve. In this post, I discuss my journey away from BEM and SASS towards a more composable, rapid development workflow provided by Tailwind CSS.
The Problem with BEM
BEM (Block Element Modifier) gave us a naming convention that solved specificity wars. But it also gave us class names like .card__header--highlighted-active, and stylesheet files that grew endlessly alongside our component trees.
The core issue: you’re maintaining two parallel structures — your HTML and your CSS — and keeping them in sync becomes increasingly painful as a project scales.
What Tailwind Gets Right
Tailwind’s insight is that most CSS you write is not reusable. You write margin-top: 1.5rem once for one specific element. Why give it a name? Why put it in a separate file?
<div class="mt-6 p-4 bg-white rounded-lg shadow-sm">
<h2 class="text-xl font-semibold mb-2">Title</h2>
<p class="text-gray-600 leading-relaxed">Content here.</p>
</div>
Every style decision is visible right where the element is defined. No context switching. No hunting through stylesheets.
When Tailwind Is Wrong
It’s not universally better. Long-form prose styling, complex animations, and highly dynamic themes are all cases where traditional CSS or CSS-in-JS solutions still shine. The key is knowing when to reach for which tool.