The Tailwind versus CSS Modules conversation has been one of the longer-running debates in frontend development. In May 2026 the debate has cooled somewhat — most teams have picked one approach and moved on, and the practical advantages and disadvantages of each are better understood than they were three years ago. A working read of where the trade-offs actually sit now.

The honest framing: both approaches work in production. Both have meaningful adoption at scale. Both have real trade-offs. The decision is more about team fit and codebase characteristics than about one approach being objectively better.

Tailwind CSS — the utility-first approach.

Tailwind provides a large library of utility classes that you apply directly in your component markup. Margin, padding, colour, typography, layout, interaction states — almost everything you would set with CSS has a corresponding Tailwind utility class. The styling lives in the markup. The CSS file is essentially the Tailwind library plus your customisations.

Tailwind’s appeal:

Fast iteration. Once you have the Tailwind vocabulary in your head, building a UI component is fast. You think the styling you want, you write the class, you see the result. No file-switching, no naming, no class-method-thinking. The iteration loop is tight.

Consistency by default. The Tailwind design system gives you a constrained palette of spacing, colour, and typography options. The team using Tailwind defaults to a consistent design vocabulary rather than each developer picking their own pixel values.

Easier removal. Deleting a component is genuinely just deleting a component. There is no orphan-CSS-to-track-down because the styles lived inside the component markup.

Smaller production CSS. The Tailwind build process generates only the utility classes that are actually used. The production CSS is typically smaller than the equivalent custom-CSS approach for the same component library.

Tailwind’s friction:

Marked-up class lists. The class attributes on Tailwind components can get long. A typical interactive component might have 15-30 utility classes on a single element. The visual density of the markup is high.

Cognitive load on the markup. The eye has to parse “the structure” and “the styling” simultaneously when reading Tailwind markup. Some developers find this an advantage (everything is in one place) and some find it a disadvantage (the structural shape of the markup is obscured by the styling).

Component-extraction discipline. Tailwind works best when repeated styling patterns are extracted into components rather than copy-pasted. Teams that do not enforce extraction discipline can end up with the same long class lists repeated across many places. The cost of fixing this later is meaningful.

Learning curve. The Tailwind vocabulary is large. A developer joining a Tailwind codebase has to learn the utility-class system before they can be productive. The learning curve is finite but real.

CSS Modules — the scoped-stylesheet approach.

CSS Modules treats each component’s CSS as a separate scoped stylesheet. Class names are automatically scoped to the component (typically by hashing or by build-time transformation). You write CSS in a .module.css file alongside the component, import the styles into the component, and reference them as object properties.

CSS Modules’ appeal:

Standard CSS. You write CSS. All the CSS you know works. Pseudo-classes, media queries, complex selectors, animation keyframes — all standard CSS. There is no learning curve for the basic styling work.

Markup clarity. The component markup contains markup. The styling lives in the .module.css file. Reading the JSX is reading the structure. Reading the CSS is reading the styling. The separation works for many developers.

Sophisticated styling. Complex selectors, nested rules (with PostCSS), and CSS features that go beyond utility-class patterns are easier to write in raw CSS than in utility-class form.

Established mental model. Developers from a wide range of backgrounds know CSS. The mental model of CSS Modules — scoped CSS files alongside components — is straightforward for most experienced frontend developers.

CSS Modules’ friction:

File-switching during iteration. The styling loop involves switching between the component file and the CSS file. The iteration cycle is slightly longer than the Tailwind in-line approach.

Naming pressure. Every meaningful style block needs a class name. The naming of styling concerns is real cognitive work and teams without naming discipline produce CSS files with generic and reused class names that defeat the scoping benefits.

Orphan styles. Deleting a component leaves orphan styles in the .module.css file unless someone notices and removes them. Over time the CSS bundle accumulates dead styling.

Consistency requires discipline. CSS Modules does not constrain you to a design system. Teams using CSS Modules without a strong shared design language often end up with inconsistent spacing and colour across the codebase.

The third option that has gained ground — CSS-in-JS variants.

Several CSS-in-JS approaches have continued to be used in 2026, including stitches and the modern styled-components patterns, although the bundle-size implications and the runtime cost of older CSS-in-JS approaches have pushed many teams away from them. The recent generation of CSS-in-JS approaches with zero-runtime extraction (vanilla-extract, panda-css) gives some of the CSS-in-JS ergonomics without the runtime cost.

What is working in production in 2026:

Tailwind is dominant at startups and at fast-iteration teams. The speed of iteration and the built-in design system fit the operating mode of startups well. Most new startup React codebases I see in 2026 are using Tailwind.

CSS Modules is dominant at established codebases with complex styling. The teams that have invested in design systems with sophisticated component-level styling often prefer the explicit CSS Modules approach. The Next.js framework default of CSS Modules is part of the reason for the continued strong adoption.

Hybrid approaches are increasingly common. Many teams use Tailwind for the bulk of utility styling and CSS Modules for the more complex component-specific styling. The two approaches coexist well in the same codebase if the team has clear conventions about when to use which.

Choice considerations for a new codebase in 2026:

Team familiarity. If the team is familiar with Tailwind and has built Tailwind codebases before, Tailwind is the faster choice. If the team is familiar with CSS Modules, CSS Modules is the faster choice. Switching just to follow the fashion is rarely worth the cost.

Codebase size projection. For codebases that will stay small (a marketing site, an internal tool, an early-stage product), either approach is fine. For codebases that will grow large with multiple developers contributing, the design-system discipline that Tailwind enforces becomes more valuable as the team grows.

Styling complexity. For codebases with simple-to-moderate styling needs, Tailwind handles 95% of the styling cleanly. For codebases with complex styling needs (sophisticated animations, intricate responsive layouts, design-heavy UI), CSS Modules gives more direct control.

For developers picking a styling approach for a new codebase in 2026, the honest answer is that both approaches work well in production at scale and the choice is a team and codebase fit question. Pick the approach that the team can be most productive in, invest in the design system that goes with it, and do not spend a lot of time second-guessing the choice once it is made.

The Tailwind versus CSS Modules debate is no longer interesting in the way it was in 2022. The interesting frontend styling conversations in 2026 are mostly about design systems, accessibility patterns, and animation libraries rather than about the underlying CSS approach.