Tailwind CSS vs Classic CSS: The Right Choice

Tailwind CSS changed how sites get styled, to the point that the question is largely settled among developers: in 2026 it dominates React, Next.js and Astro projects. The real question, the one that matters to whoever pays for a site rather than writes it, is what that choice costs in maintenance and in lock-in.

Key takeaways. Classic CSS separates style from HTML, Tailwind puts it inside. Neither is better in itself: classic CSS wins when you do not control the markup, Tailwind wins as soon as there are components. And if you do not write code, only one criterion concerns you: both are standards another provider can pick up, which is not true of a proprietary theme.

The difference, in two blocks of code

The same button, written both ways. That is the whole debate, and it fits in ten lines.

.btn-primary {
  padding: 0.5rem 1rem;
  border-radius: 0.5rem;
  background: #2563eb;
  color: white;
  font-weight: 600;
}
.btn-primary:hover {
  background: #1d4ed8;
}

<button class="px-4 py-2 rounded-lg bg-blue-600 text-white font-semibold hover:bg-blue-700">
  Send
</button>

In the first case the style lives in a separate file and the HTML stays readable. In the second everything sits in one place and there is no class name to invent. Everything else in this article follows from that single difference.

Classic CSS: what it wins and loses

Traditional CSS separates style from HTML. You create semantic classes, `.card`, `.btn-primary`, and write the rules in separate `.css` files. It is how the browser works natively, with nothing else required.

Advantages of classic CSS

• Clean HTML: the markup stays readable and semantic, which matters when someone else picks up the file.
• Immediate reuse: one class equals one style applied everywhere, without going through a component.
• No dependency: no build tool, no version to track, the file still works in ten years.
• Total control: you write exactly what you need, no more and no less.

Disadvantages of classic CSS

• Files grow, and nobody dares delete a rule when they cannot tell where it still applies.
• Naming is a craft of its own. BEM, OOCSS and SMACSS exist precisely because naming things is hard.
• Dead CSS piles up: classes from a section removed two years ago are still downloaded by your visitors.
• Jumping between HTML and CSS slows you down, especially on a project you do not know by heart.

Tailwind: what it wins and loses

Tailwind offers atomic utility classes: one class, one property. The framework does not ship a fixed stylesheet, it generates the CSS from the classes you actually use by scanning your files. That explains most of its advantages, and its main drawback.

Version 4, released in early 2025 and now at 4.3 through 2026, replaced the engine. Compilation runs on Oxide, partly written in Rust: the team reports building their own site in 105 ms against 960 ms before, an install 35% smaller, and configuration that now happens in CSS rather than JavaScript.

Advantages of Tailwind

• Fast development: no need to leave the file, and no class name to invent for a button used once.
• No dead CSS: only classes present in the code produce CSS, so the stylesheet cannot bloat with orphan rules.
• Built-in design system: spacing, colours and sizes come from one scale, which prevents the twenty-three shades of grey of a loosely managed project.
• Responsive and dark mode by prefix: `md:flex`, `dark:bg-gray-800`, without writing a single media query.

Disadvantages of Tailwind

• The markup gets verbose. A button can carry twelve classes, and skimming the HTML becomes painful.
• You have to learn the vocabulary. A few days to get comfortable, and that knowledge does not transfer anywhere else.
• A build tool is mandatory. Without it no class produces any style, which rules out contexts where nothing can be compiled.
• Very specific cases stay verbose, and you fall back on the square-bracket syntax, which reads less well.

The comparison, criterion by criterion

What it changes for you if you do not write code

This is the part comparisons skip, though it is the only one that binds you. Three concrete consequences.

Handover to another provider. Both approaches are public, documented standards known to tens of thousands of developers. A proprietary theme or a visual builder is not: picking those up means buying the same licence and learning a closed tool. On this criterion, Tailwind versus classic CSS is a false debate. Both leave you free.

The cost of changes. On a component-based site, changing the accent colour happens in one place either way. On a site where style was written page by page, which happens more often than anyone admits, Tailwind makes the change faster because the value sits where you read it.

Perceived performance. It is decided elsewhere: unoptimised images, blocking fonts, third-party scripts. CSS weight is rarely a brochure site’s problem, and choosing Tailwind to save a few kilobytes would be choosing for the wrong reason.

The hybrid approach, and the @apply trap

Nothing stops you combining both, and that is what I do on most projects: Tailwind for layout and utilities, hand-written CSS for the few places that call for it.

A correction to the first version of this article, where I recommended `@apply` for repeated components. The official documentation does not point that way: faced with duplication it suggests loops first, then multi-cursor editing, then components or template partials, and only mentions hand-written CSS when a partial would be heavy-handed for a simple button (Tailwind documentation, managing duplication, retrieved 1 September 2026). In practice `@apply` recreates the problem Tailwind solves: a layer of indirection between what you read and what applies.

The question that settles it

Do you control the HTML? If yes, and there are components, Tailwind. If no, because the markup comes from a CMS, a third-party module or an email template, classic CSS, without hesitating.

The rest, the learning curve, the verbosity, everyone’s preferences, is worth discussing but does not decide. And this choice comes after the framework, which has far more effect on the result: see Next.js versus Astro if that question is still open.

Frequently asked questions

Does Tailwind slow my site down?

No, rather the opposite. Because the CSS is generated from the classes actually present, the shipped stylesheet contains nothing useless. On a brochure site it usually weighs less than a hand-written stylesheet that was never cleaned up.

Can another developer pick up a Tailwind site?

Yes. It is a widely adopted standard, the documentation is public, and the syntax takes a few hours to learn for anyone who knows CSS. Real lock-in never comes from the styling framework; it comes from proprietary themes and visual builders.

Should an existing site be migrated to Tailwind?

Rarely for its own sake. A styling migration costs days and shows your visitors nothing. It makes sense alongside a redesign already decided for other reasons, not as a project in itself.

In short

Tailwind is not better than classic CSS, it is a different tool for a different context. It dominates component-based projects, classic CSS remains the only option when the markup is out of your hands, and both leave you free to change provider. If you are not writing the code yourself, that last point is the one that counts, and it holds either way.

Sources retrieved on 1 September 2026: Tailwind documentation, styling with utility classes and the Tailwind team’s announcement of the Oxide engine.