Tailwind CSS v4: What’s New and When It Makes Sense

Tailwind CSS didn’t win by being clever. It won by making the boring parts of styling — naming, specificity, dead code — someone else’s problem. v4 continues that direction with a faster engine, a cleaner configuration model, and better alignment with where CSS itself is heading. Here’s what matters for teams building products today.

Why utility-first still makes sense for product teams

The case hasn’t changed: constraints beat freedom when you’re moving fast with multiple contributors. Utility classes mean no naming debates, no specificity battles, and no stylesheet that grows without bound. The tradeoff — verbose markup — disappears when you extract components properly.

Specific wins that hold in v4: dead-code elimination keeps bundles lean, spacing and color tokens map directly to Figma variables, and responsive/state variants (md:, hover:, focus-visible:, aria-) encode interaction design where it belongs — next to the element it affects.

What’s actually new in v4

The headline change is the engine rewrite (Oxide) — build times are significantly faster on large codebases. The bigger shift for teams is the move toward CSS-first configuration: v4 reduces reliance on tailwind.config.js in favour of defining tokens directly in CSS using @import "tailwindcss" and CSS custom properties. This aligns Tailwind more closely with native CSS cascade layers and modern browser capabilities including P3 color support.

How to use it well

Design tokens belong in config, not scattered as magic numbers in JSX. When your brand color changes, one token update should ripple everywhere — not a find-and-replace across 40 files.

Repeated class strings should become components. <Button variant="primary"> is an API. Thirty utilities copy-pasted across twelve files is technical debt with good intentions.

For dark mode in product apps, class-based switching remains the controllable approach. System-preference dark mode works well for marketing pages; for app UIs where users expect a persistent toggle, class-based is cleaner.

What to avoid

Copy-pasting long class strings without extracting components defeats the purpose. Adding large custom CSS layers “just this once” creates exactly the specificity problems Tailwind exists to prevent. And ignoring focus-visible: styles is an accessibility failure — not a style preference.

Tailwind vs CSS Modules vs styled-components

All three are defensible. Tailwind optimises for speed and system consistency — it’s the right default for product teams that want to move fast without a dedicated design system engineer. CSS Modules suit teams that prefer explicit scoping and want CSS closer to traditional authoring. Styled-components and CSS-in-JS solutions work well when component-level dynamic theming is a core requirement. The honest answer: choose based on team fluency, not internet consensus.

Frequently asked questions

Should I upgrade to Tailwind CSS v4 right away?

If you’re starting a new project, absolutely. For existing applications, there’s no need to rush. If your current Tailwind setup is stable, plan the upgrade when it fits your roadmap rather than treating it as an urgent migration.

Is Tailwind CSS better than CSS Modules?

It depends on how your team likes to build software. Tailwind is great when consistency, speed, and a shared design system matter most. CSS Modules are still an excellent choice for teams that prefer writing traditional CSS with locally scoped styles. Neither is objectively better—they optimize for different workflows.

Does using Tailwind mean I don’t need to learn CSS?

Not at all. Tailwind is built on top of CSS, not instead of it. Understanding layout, the cascade, Flexbox, Grid, spacing, and accessibility is still essential. Tailwind simply gives you a more structured way to apply those fundamentals.