The debate about Tailwind CSS has never really been about Tailwind. It's about what you believe styling architecture should look like, and that belief tends to be strongly held on both sides. Since Adam Wathan published his original "CSS Utility Classes and Separation of Concerns" post in 2017 and then shipped Tailwind v1 in 2019, the argument hasn't cooled — it's just moved to different arenas. In 2025 and 2026, the criticism has sharpened because the ground beneath it changed: native CSS grew up.
This isn't a hit piece. Tailwind is genuinely the most-used CSS framework in 2025, with roughly 37% of developers actively using it according to the State of CSS survey. That adoption isn't an accident. But a meaningful subset of developers — particularly those who joined the Tailwind wave during 2020–2022 — have been migrating back to plain CSS or lower-abstraction alternatives. Their reasons are worth examining honestly.
What actually changed with Tailwind v4
Before getting to the criticism, it's worth understanding what Tailwind v4 (released in January 2025) modified. The rewrite was genuine. The new Oxide engine delivers full builds roughly 3.5x faster and incremental builds over 100x faster in cases where no new CSS is generated. Build speed was a real pain point at scale, and Tailwind largely fixed it.
The bigger architectural change was moving configuration from JavaScript to CSS. Where you previously maintained a tailwind.config.js, v4 lets you define your design system directly in CSS using @theme:
@import "tailwindcss";
@theme {
--color-brand-500: oklch(0.84 0.18 117.33);
--breakpoint-3xl: 1920px;
}
This is a meaningful improvement: your design tokens are now native CSS custom properties, exposed to JavaScript at runtime without any extra wiring. Tailwind v4 also removed the PostCSS dependency for most setups, added built-in container query support, and incorporated native cascade layers under the hood.
So the honest framing for the rest of this article is: if your criticisms were primarily about performance or configuration ergonomics, v4 addressed them. If your criticisms were about the fundamental model of utility-first CSS, v4 changed nothing. That's where the real argument lives.
The legitimate technical arguments against utility-first CSS
Markup verbosity and the readability tax
The most common complaint about Tailwind is that your HTML ends up looking like this:
<button class="flex items-center gap-2 rounded-md bg-blue-600 px-4 py-2 text-sm font-semibold text-white shadow-sm hover:bg-blue-500 focus-visible:outline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-blue-600 disabled:opacity-50">
Submit
</button>
This is the class-soup problem. Critics argue it doesn't just look bad — it creates a real cognitive cost. When you're scanning markup to understand a component, you're reading styling before reading structure. The text content of the button, the semantic element, the data attributes — they're buried under 15 classes.
Defenders correctly point out that the alternative, semantic class names like btn-primary, hide exactly as much information: you still need to look somewhere to know what btn-primary does. But that somewhere is a CSS file with named selectors, which is what tools like browser DevTools were designed to navigate. With Tailwind, DevTools shows you 15 separate properties applied from 15 separate classes, which makes debugging specificity and cascading behavior harder to trace at a glance.
The verbosity isn't purely cosmetic. Onboarding engineers unfamiliar with Tailwind's naming conventions face a real translation burden. pt-4 means padding-top: 1rem. justify-center and items-center look parallel but target different flex axes. border renders a 1px border, not border-1 as you might guess. These are learnable quirks, but there are many of them, and the mental translation cost during code review is not zero.
The bet against the cascade
Here's the more technically interesting criticism. Tailwind's utility-first model is fundamentally a bet that you should style by composing small classes rather than writing selectors that take advantage of CSS's cascade.
For a long time, that bet made sense. The cascade was genuinely hard to manage at scale. Specificity wars were common. Global styles leaked into components unpredictably. Tailwind sidestepped the problem by flattening everything to single-class utilities with roughly equal specificity.
But in 2025, native CSS has features that address exactly those cascade management problems. CSS cascade layers, now supported in all modern browsers at above 90% coverage, let you explicitly declare priority order for style rules. CSS nesting, clearing 95%+ support, removes the main reason developers reached for Sass. Container queries, :has(), color-mix() — these aren't hypothetical. They're shipping.
The argument against Tailwind isn't that these features existed before. It's that Tailwind's utility model actively discourages learning them. When you spend your day writing md:flex instead of @media (min-width: 768px), you're building fluency in Tailwind's abstraction layer, not in CSS itself. If you leave a Tailwind project, or if Tailwind's API changes meaningfully (as it did between v3 and v4), that knowledge doesn't transfer cleanly.
If you want to stress-test your own CSS knowledge, try writing a moderately complex layout with only native CSS — cascade layers for organization, nesting for state variants, container queries for component-level responsiveness. The exercise will tell you exactly how much of your current skill lives in Tailwind and how much lives in CSS fundamentals.
Design system drift via arbitrary values
Tailwind's design token system is one of its genuine strengths. When your entire team uses text-blue-600 from a shared palette, you get consistency almost for free. The problem is the escape hatch: arbitrary values.
w-[347px], text-[#1a2b3c], mt-[13px] — these bypass the design system entirely. They're in the documentation, they're frequently used, and they're very hard to lint into submission on large teams. An enterprise e-commerce team documented in a 2026 article that teams lost meaningful time on front-end change tickets due to unclear conventions, eventually reintroducing abstracted components to manage the inconsistency.
This isn't a problem Tailwind created, but it's one Tailwind's flexibility enables. A strict CSS architecture with defined tokens and linting rules can achieve the same guardrails, but it requires deliberate setup — the same setup Tailwind was supposed to eliminate.
Why Tailwind still works, and works well
The criticisms above are real. They're also not universal. Tailwind's dominance isn't cargo-cult thinking; it solves specific problems particularly well.
Component-scoped work. If you're building in React, Vue, or Svelte with well-isolated components, the verbosity problem is contained. Utility classes are co-located with the markup they style. You don't hunt for a class definition in a separate file because there isn't one. This is a genuine developer experience win, especially on teams where context-switching between CSS files and component files adds up over a day.
AI-assisted development. AI code generation tools produce Tailwind markup with high fidelity. When you're using Cursor or Claude Code to scaffold components, Tailwind's explicit class syntax is easier for models to generate correctly than semantic CSS because it's more deterministic. The class name directly encodes the style intent.
Onboarding for teams without a CSS specialist. For teams where CSS architecture isn't anyone's core competency, Tailwind's constraints — use these predefined scales, compose from these utilities — produce more consistent output than unconstrained CSS. The ceiling is lower but so is the floor.
v4's CSS-first configuration. Exposing design tokens as native CSS custom properties is a meaningful improvement. Your --color-brand-500 token is now available to JavaScript, to inline styles, to calc() expressions, and to any third-party component that knows how to read CSS variables. This closes a real gap.
Who should actually reconsider it
The developers who have legitimate reasons to move away from Tailwind in 2026 generally fall into a few categories.
Teams building content-heavy or server-rendered sites where HTML semantics and file size matter, and where the styling complexity is low. For a marketing site or a documentation site, the overhead of Tailwind's class verbosity rarely pays for itself compared to a few well-organized CSS files.
Developers who want to build CSS fluency. Using Tailwind as your only styling tool means you're learning one framework's abstraction of CSS, not CSS itself. If you're early in your frontend career and you want to be employable across different stacks, spending intentional time with vanilla CSS is not wasted.
Teams with large existing codebases and strong CSS infrastructure. If you have a mature SCSS or vanilla CSS codebase with established naming conventions and linting rules, the migration cost to Tailwind is real and the benefit is incremental. The teams most likely to see the biggest Tailwind benefit are the ones starting from scratch.
Anyone finding the v3-to-v4 migration painful. The CSS-first configuration shift broke a lot of existing tooling and component library integrations. If you're mid-migration and the friction is high, stopping to evaluate whether the upgrade is worth it is reasonable.
For the majority of teams — especially those building component-driven SPAs, using shadcn-ui or similar ecosystems, and working with AI coding tools — Tailwind v4 is a solid choice with no compelling reason to leave.
The argument against Tailwind is not that it's bad software. It's that native CSS has absorbed enough of its value proposition that the tradeoffs deserve re-examination rather than acceptance by default. That's a more honest frame than the discourse usually gets.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
