Tailwind CSS: The Framework That Changed How I Write CSS

I used to hate writing CSS. There, I said it.

Not because CSS itself is bad, but because of everything that came with it: naming classes, organizing files, fighting specificity wars, and maintaining stylesheets that grew into unmaintainable monsters. I’d spend more time thinking about what to name a button class than actually building the button.

Then I tried Tailwind CSS, and honestly? It felt wrong at first. Really wrong.

The “Ugly” Phase

My first reaction to Tailwind was visceral rejection. Look at this:

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Click me
</button>

“This is disgusting,” I thought. “We moved past inline styles for a reason!” I closed the tab and went back to my carefully crafted BEM methodology and SCSS files.

But a few weeks later, a project deadline was crushing me. I was stuck in CSS hell, debugging why a modal wasn’t centering properly, fighting with some global style that was leaking in from who-knows-where. Desperate times, desperate measures. I gave Tailwind another shot.

The Click Moment

Press enter or click to view image in full size

Here’s what changed my mind: I stopped context switching.

With traditional CSS, my brain is constantly jumping:

• Write HTML structure
• Switch to CSS file
• Think of a class name
• Write the styles
• Switch back to HTML
• Add the class
• Refresh browser
• Realize it’s not working
• Switch back to CSS
• Debug specificity issues
• Repeat forever

With Tailwind, I just… build. The component is right there. I see 

flex items-center justify-between

 and I know exactly what's happening. No hunting through files. No wondering if 

.header-nav-item

 is defined somewhere or if I'm supposed to use 

.nav-header-item

 instead.

It’s Not Just About Speed

Sure, I build faster now. But the real win is maintenance.

Six months later, I can look at my Tailwind components and understand them immediately. There’s no mystery CSS file with a comment that says “don’t touch this or everything breaks.” There’s no cascade of inheritance creating unexpected behaviors three components deep.

When I need to make a button slightly bigger, I change 

px-4

 to 

px-6

. Done. I don't need to find the SCSS file, locate the button mixin, update the padding variable, and hope it doesn't break buttons somewhere else.

The Learning Curve is a Lie

People say Tailwind has a steep learning curve. They’re wrong. The curve exists, but it’s not steep — it’s just different.

You’re not learning new concepts. You’re learning a naming system. And it’s consistent! Once you understand that 

p-4

 means padding and 

m-4

 means margin, you can probably guess what 

mt-4

 means (margin-top). The pattern holds across everything.

I learned enough Tailwind to be productive in about 30 minutes. Becoming fluent? Maybe a few days of actual use. Compare that to mastering CSS architecture patterns, and it’s not even close.

What I Actually Love About It

Responsive design is beautiful. Instead of media queries scattered everywhere:

<div class="text-sm md:text-base lg:text-lg">
  This scales naturally
</div>

Dark mode is trivial. Just prefix with 

dark:

:

<div class="bg-white dark:bg-gray-800 text-black dark:text-white">
  Works instantly
</div>

Customization is powerful. People think Tailwind makes everything look the same. That’s like saying Photoshop makes every photo look the same. Your 

tailwind.config.js

 file is where your design system lives. You define your colors, spacing, fonts—everything. Then you use those consistently across your entire app.

It forces good practices. When every utility is visible in your HTML, you notice when you’re repeating yourself. That’s your signal to extract a component. With traditional CSS, bloat hides in files you’re not looking at.

When Tailwind Isn’t The Answer

Let me be real: Tailwind isn’t perfect for everything.

If you’re building a simple blog or a content-heavy site where you’re mainly styling markdown, traditional CSS might be simpler. If your team is resistant and you don’t have buy-in, forcing it will create problems.

And yes, the HTML can get verbose for complex components. That’s when you use your framework’s component system (React, Vue, whatever) to abstract things. A 

<Button variant="primary" size="lg">

 component can contain all those Tailwind classes internally.

The Verdict After Two Years

I’ve shipped dozens of projects with Tailwind now. I’ve gone back to maintain year-old codebases and been shocked at how easy it still is. I’ve onboarded new developers who became productive in days, not weeks.

Would I use Tailwind for every project? No. But for 90% of the web applications I build? Absolutely.

The framework didn’t just change how I write CSS. It changed how I think about styling. I spend less time fighting my tools and more time building products. And isn’t that the whole point?

If you haven’t tried Tailwind seriously — and by seriously, I mean building at least one complete feature with it — you owe it to yourself to do so. Push through that initial “this feels wrong” phase.

You might just have the same click moment I did.

What’s your experience with Tailwind? Still team semantic CSS, or have you made the switch?