Tailwind CSS vs. Traditional CSS: Why I Stopped Writing Style Sheets

I used to be a CSS purist. 🎨

"Just learn CSS properly," I'd say, smugly, while writing my 47th .card-container-wrapper-inner class.

Then I tried Tailwind. And reader, I became a convert.

😤 The Old Me: Why I Hated Tailwind

My complaints were valid. Or so I thought.

"The HTML looks ugly!"

<div class="flex items-center justify-between px-4 py-2 bg-blue-500 hover:bg-blue-600 rounded-lg shadow-md"></div>

Gross, right? Unreadable. What is this, 1999 inline styles?

"You're just moving CSS into HTML!"

Exactly! And that's... bad? I assumed it was bad. Everyone on Twitter said it was bad.

"What about separation of concerns?"

Ah yes, the sacred principle I'd learned in a bootcamp and never questioned.

🔄 The Moment I Switched

I joined a project with a massive CSS codebase.

Did you know? The average enterprise CSS file is 50,000+ lines. Half of it is dead code no one dares to delete because "what if something breaks."

I spent HOURS:

• Searching for the right class name
• Checking if .btn-primary-lg was different from .btn-lg-primary
• Debugging specificity wars
• Crying in the break room

Then a teammate said: "Why don't we just use Tailwind?"

I rolled my eyes. I agreed reluctantly. I prepared to be proven right.

I was not proven right.

🎯 What Actually Changed

1. No More Context Switching

Before: Write JSX → Open CSS file → Create class → Go back → Repeat After: Write JSX with styles → Done

I didn't realize how much mental energy context-switching burned until it stopped.

2. No More Naming Things

The two hardest problems in computer science:

1. Cache invalidation
2. Naming things
3. Off-by-one errors

Tailwind eliminates #2 for styling. I never have to decide between .card-header, .cardHeader, or .card__header ever again.

3. Design Consistency is Built In

Tailwind's spacing scale (4, 8, 12, 16...), colors, and breakpoints are all predefined.

Did you know? Most "design inconsistency" bugs come from one dev using margin: 15px and another using margin: 1rem. Tailwind makes this impossible by only offering consistent values.

4. Deleting Code is Safe

With traditional CSS, deleting a class is terrifying. What if it's used somewhere? What if there's specificity magic happening?

With Tailwind, if you delete the HTML, the styles go with it. No orphaned classes. No fear.

⚠️ The Downsides (Being Honest)

• Learning curve: You need to memorize utility classes (or keep the docs open forever)
• Long class strings: Some elements look like alphabet soup
• Not great for highly custom designs: Complex animations still need real CSS
• Team adoption: Getting everyone on board can be... political

🏆 My Setup Now

I use Tailwind for:

• Layout (flexbox, grid)
• Spacing
• Colors
• Typography
• Responsive breakpoints

I use regular CSS for:

• Complex animations
• Very specific one-off styles
• Third-party component overrides

Best of both worlds. No dogma.

🎤 The Verdict

If you're still fighting with traditional CSS and think Tailwind is "cheating"—I get it. I was you.

But try it on one real project. Not a tutorial. A real, messy, complex project.

Then come back and tell me you miss writing .card-container-wrapper-inner-bottom-left-corner-highlight.

I'll wait. ☕