The Tailwind CSS Debate: 3 Years Later

I’m going to be honest with you: the first time I saw Tailwind CSS, my gut reaction was “this is just inline styles with extra steps.” And then I did what I always do - I used it anyway. Because I have a condition where I cannot encounter a new technology without giving it a real, obsessive chance. I strongly suspect it’s undiagnosed ADHD. I call it a competitive advantage.

This site - 211j.com, the one you’re reading right now - is built with Tailwind. I use it at my day job at StudioRx. I’ve been writing it daily for long enough to have opinions that are actually grounded in production experience, not in a hot take I wrote after reading the docs for twenty minutes.

The Initial Skepticism Was Real (But Short-Lived)

I’m a CSS person. I came up writing stylesheets by hand, obsessing over specificity, building component architectures with BEM and SMACSS. So yeah, when I first saw class="bg-blue-500 text-white px-4 py-2 rounded-lg hover:bg-blue-700", something in my soul recoiled.

But I tried it. On an actual project, not a toy. And within about two days, something shifted. I was building UI faster than I ever had with traditional CSS. Not a little faster. Dramatically faster.

What I Actually Like

I stopped naming things. Naming CSS classes is one of the hardest problems in front-end development, and I’m not even being hyperbolic. How many hours of your life have you spent debating whether it should be .card-header-title or .card__header-title or .cardHeaderTitle? With Tailwind, the answer is: none of them. You just describe what the thing looks like.

The design system is built in. Tailwind’s spacing scale, color palette, and typography system mean that p-4 is always the same padding everywhere. text-lg is always the same size. You stop making up random pixel values and start working within constraints. My designs got more consistent without me trying harder.

Dead CSS disappeared. With traditional CSS, deleting an HTML component means hunting through stylesheets for orphaned rules. With Tailwind, delete the element and the styles go with it. This matters more than people think on long-running projects.

Team collaboration improved. At StudioRx, working alongside a full dev team, Tailwind solved a real problem: people stepping on each other’s CSS. When styles are co-located with markup, you stop having specificity wars and mysterious overrides from some stylesheet someone wrote two years ago.

What Still Drives Me Nuts

I’m not a Tailwind evangelist. There are things that genuinely annoy me:

The HTML gets ugly. There’s no sugarcoating this. A complex responsive layout in Tailwind looks like someone sneezed utility classes all over your markup. I’ve written divs with class lists so long they need their own scroll bar. It’s not pretty.

Responsive prefixes stack up fast. sm:flex md:grid md:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 - at a certain point you’re writing more Tailwind than you would have written in a media query. The breakpoint ergonomics could be better.

Dynamic classes and purging. If you’re generating class names dynamically in JavaScript - say, mapping a color variable to bg-${color}-500 - the purge step will nuke those classes from your production build because it never sees them in your source code. This has bitten me more than once.

You need component extraction or you’ll lose your mind. Tailwind without components (React, Vue, Blade partials, whatever) means copy-pasting the same 15-class string everywhere. The framework basically requires a component-based architecture to stay sane.

The WordPress Integration

Using Tailwind with WordPress is a slightly different animal than using it with a React app. WordPress themes have their own opinions about markup, Gutenberg blocks add their own classes, and you’re often styling content that comes out of a WYSIWYG editor where you can’t add utility classes.

For block themes, Tailwind works well - you control the templates and can utility-class to your heart’s content. For the post content area, you need Tailwind’s Typography plugin (@tailwindcss/typography) to handle the prose styling, because you’re not going to add utility classes to every paragraph tag that comes out of the editor.

It’s not seamless, but it works. This site is proof.

The Performance Surprise

One of my early concerns was file size. Shipping every utility class in the framework would be enormous. But Tailwind’s purge system (now called “content” configuration in v3+) strips out every class you don’t use, and the result is a CSS file that’s typically smaller than what I’d write by hand.

The production CSS for this site is tiny. Smaller than most single-component stylesheets I wrote in the BEM days. The atomic nature of utility classes also compresses better with gzip because the repeated patterns are exactly what compression algorithms are good at.

Tailwind vs. What I Used to Do

The honest comparison isn’t “Tailwind vs. perfect hand-crafted CSS.” It’s “Tailwind vs. what actually happens on real projects with real deadlines and real teams.” And what actually happens is: CSS files that grow forever, specificity hacks layered on top of each other, a dozen slightly different shades of gray because nobody checked the existing variables, and a stylesheet that nobody wants to touch because they’re afraid of breaking something.

Tailwind doesn’t eliminate bad decisions. But it constrains you in ways that make bad decisions harder to make, and that’s worth a lot.

Who Should Use It

If you’re building component-based UIs (React, Vue, WordPress block themes with PHP templates), Tailwind is a genuine productivity multiplier. If you’re on a team, the consistency benefits are hard to argue with. If you like working fast and you’re willing to accept ugly HTML as the trade-off, give it a real shot. Not a weekend experiment - an actual project.

If you’re building a simple brochure site, vanilla CSS is fine. If you’re working on a legacy codebase with years of existing styles, migrating to Tailwind probably isn’t worth the pain. Context matters.

The Bottom Line

Tailwind is the tool I was skeptical of for about 48 hours before my FOMO kicked in, and it’s now the tool I reach for on every new project. It’s not perfect. The HTML is ugly, the responsive syntax is verbose, and the purge system will bite you if you’re not careful. But it makes me faster, my designs more consistent, and my team more productive.

I’m not going to tell you it’s the future of CSS. But it’s my present, and it’s working.