Tailwind CSS: Why It Works for Some Projects — And Not for Others

Tailwind CSS often sits at the center of heated debates in frontend circles. Every month, someone influential in the CSS community posts a thread explaining why we should stop using Tailwind, and every time the discussion goes viral again.

But here’s the problem: these conversations usually treat Tailwind as if everyone using it is trying to impose it on the entire world. That isn’t true. Most Tailwind users aren’t advocating to erase traditional CSS: they’re simply choosing a tool that fits their workflow, their brain, and their project needs. And that is the beauty of the web: we have different tools for different jobs.

After years of building frontend systems, my conclusion is simple: Tailwind is great for some projects and teams, and not right for others. And both stances can be true at the same time.

This article isn’t about class length, syntax preferences, or “HTML readability wars.” It’s about trade-offs, cognitive load, modern CSS capabilities, and why no tool should be imposed as a universal solution.

Tailwind Is a Good Tool. Let’s Be Honest About That

Tailwind didn’t become popular by accident. It exists because it addresses real, recurring problems in frontend teams:

• Inconsistent naming conventions and/or endless debates about class names
• Unclear ownership of styles
• Cascade-related bugs
• CSS files that grow without structure

From a company perspective, Tailwind’s biggest strength is not (only) speed, but it’s standardisation. There is one way to write classes, and that’s it. No bikeshedding, no style debates, no endless refactors.

That alone makes Tailwind incredibly attractive for teams.

It’s also worth saying this clearly: Tailwind is built by people who genuinely love CSS. In many cases, it even becomes a gateway into learning CSS, thanks to solid documentation and discoverability.

So no, this is not an anti-Tailwind article (sorry if you were looking for one, you will probably find thousands out there).

Let’s challenge some of the things that people say about Tailwind, like how easier than CSS it is.

Is Tailwind Really Easier Than CSS? Not Really

CSS is a simple language. Not easy — but simple. The syntax is stable, readable, and hasn’t fundamentally changed in years.

Tailwind doesn’t make CSS easier.

It makes it more constrained and often clearer, but not inherently simpler.

For developers who already know CSS deeply, Tailwind is an abstraction over a language they already think in. In those cases, it can actually slow things down — not because Tailwind is bad, but because translating mental models into utility classes introduces friction.

This is especially noticeable once you move beyond margins, paddings, grids, and breakpoints.

That’s where I would say tha the friction starts

Modern CSS is Where Friction starts

This is where my personal preference begins to diverge.

CSS today is far more than spacing and layout utilities. We now have:

• container queries
• fluid layouts with min(), max(), clamp()
• advanced color functions
• scroll-driven animations
• view transitions
• progressive enhancements
• smarter defaults that reduce media queries dramatically

When building fluid, modern layouts, Tailwind can start to feel… unnatural.

For example, let’s put the example of clamp:

<div class="text-[clamp(2rem,8vw,4rem)]"></div>

Or container queries:

We would do the following with CSS:

.container {
  container-type: inline-size;
}

@container (min-width: 600px) {
  .container {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

<div class="@container">
  <div class="@md:grid @md:grid-cols-[1fr_2fr]"></div>
</div>

Even though all this is technically impressive, it is also cognitively heavier.

Also, when you have arbitrary values (but I would recommend use variables)

.button {
  background: oklch(62% 0.18 255);
}

<button class="bg-[oklch(62%_0.18_255)]"></button>

All these examples are possible in Tailwind, but add friction:

• Harder to refactor (arbitrary values scattered in markup)
• Logic becomes fragmented across markup (in the case of container queries, for example)
• Harder to see layout intent holistically
• Debugging in DevTools becomes tedious

I think the big problem here is that modern CSS is moving toward fewer breakpoints, more fluid layouts and logic, more declarative intent. Tailwind, on the other hand, is still very much about atomic tokens, discrete utilities and explicit repetition.

And these philosophies clash, and diverge more and more as CSS evolves.

The Pragmatic Take

This doesn’t mean Tailwind is bad.

It means:

• Tailwind is excellent for standardized, constraint-based UI
• Modern CSS shines when pushing fluid, expressive, progressive designs
• Hybrid approaches are often the most honest solution (as I do in this website, for example)

For small, modern edge cases, writing CSS is often clearer, more readable, and more maintainable — even in Tailwind projects.

And for the people posting these big code snippets full of utility classes, I would say: if you need to write that much Tailwind code to express something, maybe it’s a sign that CSS would be a better fit for that specific case.

Or just create a class, even though you are using Tailwind, for God’s sake.

Acknowledging that isn’t a failure of Tailwind.

It’s simply respecting the language.

A Necessary Detour: The Tailwind “Haters” Problem

No discussion about Tailwind is complete without addressing the noise around it. Not constructive criticism — that’s healthy — but the repetitive, predictable backlash that appears every single time Tailwind is mentioned.

This isn’t about disagreement. It’s about how some arguments are made.

Over time, two recurring profiles emerge.

1. The CSS Preachers

These are the people who seem to have an alert system for the word Tailwind.

Every time someone posts about Tailwind — regardless of context — they immediately jump in to say:

Just use CSS.

What’s interesting is that this behavior is almost never symmetrical. You don’t see Tailwind users storming posts about messy, unstructured CSS yelling “just use Tailwind.”

The irony is hard to miss.

Many of these CSS preachers:

• sell PDFs, courses, or products around “vanilla CSS”
• operate in a very specific niche
• benefit directly from positioning Tailwind as the villain
• repeatedly use outrage and absolutism as engagement fuel

That doesn’t invalidate their expertise — many of them are excellent CSS developers — but it does skew the conversation.

Advocating for CSS is fine. Turning every Tailwind discussion into a sermon is not.

Tool choice is not a moral battleground.

2. The “I’m Faster with CSS” Challengers

This group tends to be louder and more confrontational.

They boldly claim:

I can code faster in vanilla CSS than anyone using Tailwind.

There’s a fundamental issue with this argument.

If you take two developers with the same level of experience, the same design, the same constraints, and the same familiarity with both tools, it is mathematically impossible to prove one approach is universally faster.

Why?

Because:

• speed depends on cognitive models
• speed depends on decision elimination
• speed depends on constraints
• speed depends on context

A CSS expert will obviously be faster with CSS. That doesn’t make Tailwind slow — it makes expertise transferable.

What this argument often hides is a comparison between expert CSS vs average Tailwind usage

That’s not a fair comparison. It’s a rhetorical one.

Speed is not a universal metric. It’s contextual, personal, and team-dependent.

The Bigger Picture: Bad Debates Hurt Better Decisions

The problem with these “hater” narratives is not disagreement — it’s oversimplification.

They flatten a complex reality into:

• CSS good / Tailwind bad
• real developers / fake developers
• purity / laziness

That framing helps no one.

Frontend development is already complex enough. We don’t need ideology layered on top of tooling.

Conclusion: Live and Let People Build

Tailwind is not ruining the web. CSS is not obsolete. And choosing one over the other does not define your skill as a developer.

Some people want constraints. Some people want freedom. Some people want both.

The healthiest frontend ecosystems are built on plurality, not dogma.

Use Tailwind if it helps you and your team. Write CSS when it’s clearer or more expressive. Mix approaches when that’s the best solution.

And most importantly: let people build things in peace.

Live — and let people live.

---

FAQ about Tailwind CSS

Is Tailwind bad for modern CSS?

No. Tailwind can support modern CSS features, but some of them introduce friction, verbosity, or reduced readability. In those cases, writing CSS directly can be clearer and more maintainable.

Should Tailwind replace CSS knowledge?

Absolutely not. Tailwind does not remove the need to understand CSS. In fact, using Tailwind effectively often requires good CSS fundamentals.

Is Tailwind slower than CSS?

There is no objective answer. Speed depends on the developer, the team, the project, and the constraints. Comparing speed in isolation is not a meaningful metric.

Is it wrong to mix Tailwind and CSS?

No. A hybrid approach is often the most pragmatic solution — using Tailwind for the common cases and CSS for expressive or complex ones.

Why do some CSS experts strongly oppose Tailwind?

Often because they already have deep mastery of CSS and gain little from the abstraction. That perspective is valid — but not universal.