BEM, Utility First and CSS Modules Compared in 2026

1. Why the CSS methodology still matters

A CSS methodology is not an end in itself, it is a deliberate answer to a structural problem in the language itself. CSS has no native namespace, no built in encapsulation and no guarantee that a class in file A means the same thing as in file B. Without convention, every medium sized project inevitably drifts toward global collisions, unclear specificity and a stylesheet nobody can fully delete because nobody knows which rule is still needed where. That uncertainty is the actual cost driver in grown frontends, not the line count of CSS.

The three dominant answers to this problem in 2026 are BEM, Utility First and CSS Modules. All three solve naming collisions and cascade chaos, but in fundamentally different ways: BEM through a strict naming convention, Utility First through small, reusable classes without semantic binding to a component, CSS Modules through automatic scoping at build time. Choosing the right CSS methodology depends less on personal taste than on team size, project lifetime and how much build tooling a team is willing to maintain.

This article compares all three approaches using concrete code examples and delivers a decision matrix at the end. The goal is not to crown a single CSS methodology as the winner, but to lay out the criteria a team can use to make its own decision instead of following a trend that does not fit its own project context.

2. BEM: Block, Element, Modifier in detail

BEM stands for Block, Element, Modifier and is the oldest of the three approaches discussed here, originally developed at Yandex. The core idea: every component is a block, every child element within that block is appended with a double underscore, and variants are marked with a double hyphen as modifiers. This CSS methodology makes a component's structure readable from the class name alone, without ever seeing the accompanying HTML structure. A developer reading card__title--highlighted knows immediately: this is the title within the card block, in the highlighted modifier variant.

The big advantage of BEM as a CSS methodology lies in flat specificity. Because every rule addresses exactly one class and never works through descendant selectors like .card .title, specificity stays consistently low across the entire project. This prevents the classic specificity war, where developers keep adding more specific selectors or !important to override older rules. BEM only enforces this discipline if the whole team follows it consistently, there is no technical mechanism that prevents a violation.

/* BEM: Block, Element, Modifier — flat specificity by convention */
.card {
  border-radius: 0.75rem;
  background: var(--color-surface);
  padding: 1.5rem;
}

.card__title {
  font-size: 1.25rem;
  font-weight: 700;
  margin-block-end: 0.5rem;
}

.card__body {
  color: var(--color-text-muted);
  line-height: 1.6;
}

/* Modifier: variant of the block, never a nested selector */
.card--highlighted {
  border: 2px solid var(--color-accent);
  box-shadow: 0 4px 12px rgb(0 0 0 / 8%);
}

/* WRONG in BEM: nested selector reintroduces specificity coupling */
/* .card .title { font-size: 1.25rem; } */

The downside shows up with deeply nested components. A block within a block quickly leads to long class names like product-list__item__price--discounted, which BEM officially discourages (elements always belong directly to the block, never to elements of elements), yet it happens frequently in practice anyway. This CSS methodology also requires that every new component is deliberately defined as its own block, which takes initial discipline but barely any tooling support, a simple linter for class names is usually enough.

3. Utility First: why Tailwind changed styling

Utility First as a CSS methodology almost completely inverts BEM's logic. Instead of semantic classes like card__title, you use small, atomic classes like text-xl font-bold mb-2, each setting exactly one CSS property. Tailwind CSS has made this approach mainstream since 2019 because it solves the biggest weakness of earlier utility frameworks, namely the lack of design consistency from arbitrary numeric values, through a fixed spacing and color system. The class p-4 means exactly the same value in every project with the default configuration, no more and no less.

The decisive advantage of this CSS methodology: developers never leave the HTML to adjust a layout. There is no separate stylesheet that needs to be maintained alongside the component, and therefore no risk of dead CSS lingering in the stylesheet after a component is deleted. Tools like the Tailwind compiler scan the markup and generate only the classes actually used, so the shipped CSS is usually noticeably smaller than a hand written BEM stylesheet with unused rules from earlier project phases.

/* Utility First: composition happens in markup, not in a stylesheet */
/* HTML (illustrative, not actual CSS):
<div class="rounded-xl bg-white p-6 shadow-md">
  <h3 class="text-xl font-bold mb-2 text-slate-900">Product title</h3>
  <p class="text-sm text-slate-600 leading-relaxed">Product description</p>
</div>
*/

/* Tailwind v4: CSS-first configuration, no separate JS config file needed */
@import "tailwindcss";

@theme {
  --color-brand: oklch(0.55 0.18 275);
  --spacing-card: 1.5rem;
}

/* Custom utility, still atomic and single-purpose */
@utility card-elevated {
  box-shadow: 0 8px 24px rgb(0 0 0 / 10%);
}

The most common criticism of this CSS methodology concerns markup readability. A component with twenty utility classes in a single class attribute line looks cluttered at first glance, especially to developers used to semantic class names. In practice this is mitigated by component extraction in frameworks like React, Vue or Blade templates, which prevent repetition anyway, so the utility list is only visible in one place in the code instead of scattered across many templates.

4. CSS Modules: local scope as a build feature

CSS Modules take a technical rather than convention based approach as the third CSS methodology. Instead of relying on naming conventions, the build process generates a unique, hashed identifier for every locally defined class, for example Card_title__x7f2a. Developers still write ordinary CSS with ordinary class names like .title, but the compiler guarantees this class never collides with a same named class in another file. That makes this CSS methodology the only one of the three where naming collisions are technically impossible rather than merely unlikely.

The import happens directly in the component file, for example import styles from './Card.module.css', and the class is then referenced as styles.title. This explicit import forces developers to actually import every class used, dead references show up immediately as build errors. Composition through composes: base from './shared.module.css' allows reusing shared base styles without classic CSS inheritance.

/* Card.module.css — class names are scoped automatically at build time */
.title {
  font-size: 1.25rem;
  font-weight: 700;
}

.highlighted {
  composes: title;
  color: var(--color-accent);
}

/* Generated output (illustrative), collision-proof by construction:
.Card_title__x7f2a { font-size: 1.25rem; font-weight: 700; }
.Card_highlighted__k93m1 { color: var(--color-accent); }
*/

/* Usage in a component:
import styles from './Card.module.css';
const el = document.createElement('h3');
el.className = styles.title;
*/

The downside of this CSS methodology is the dependency on a build step. Without a bundler like Webpack, Vite or Parcel, CSS Modules simply do not work at all, which makes them unattractive for projects without an existing JavaScript build pipeline. In addition, the generated class remains an ordinary global CSS class in the DOM at runtime, the encapsulation exists only at the level of the build tool and module boundaries, not as runtime isolation like Shadow DOM provides.

5. Hybrids: combining Utility First with BEM components

In practice many teams do not work with a single pure CSS methodology, but with a deliberate mix. A common pattern: utility classes for layout, spacing and responsive adjustments directly in the markup, while recurring, complex components like a date picker or a rich text editor get their own, BEM named component class. This component class encapsulates internal structure that is hard to express in utility classes, such as pseudo elements, complex state selectors or animation keyframes.

A second pattern combines Utility First with CSS Modules: utility classes for generic, repeated patterns, CSS Modules for components with very specific, non reusable styling. The decision of when a utility combination should be extracted into its own class usually follows a simple rule, namely once the same combination of more than three or four utility classes repeats in more than three places in the code. Tailwind's @apply directive allows exactly this extraction without fully abandoning the Utility First philosophy.

/* Hybrid pattern: extract repeated utility combinations into a component class */
.btn-primary {
  @apply inline-flex items-center gap-2 rounded-lg px-4 py-2 font-semibold;
  @apply bg-violet-600 text-white transition-colors;
}

.btn-primary:hover {
  @apply bg-violet-700;
}

/* BEM-named component class handles structure Tailwind utilities cannot express well */
.datepicker__grid {
  display: grid;
  grid-template-columns: repeat(7, 1fr);
  gap: 2px;
}

.datepicker__day--disabled::after {
  content: "";
  position: absolute;
  inset: 0;
  background: repeating-linear-gradient(45deg, transparent, transparent 4px, rgb(0 0 0 / 5%) 4px, rgb(0 0 0 / 5%) 8px);
}

6. Tooling and build pipeline differences

The three approaches differ massively in required tooling. BEM as a CSS methodology theoretically needs no build tool at all, a simple Stylelint with a BEM specific plugin rule is enough to detect violations of the naming convention. That makes BEM attractive for projects without a modern JavaScript toolchain, such as classic server rendered applications or legacy systems where an additional bundler would be politically or technically hard to introduce.

Utility First requires a CSS compiler such as the Tailwind CLI or the corresponding PostCSS plugin that scans the markup for classes used. This scan step runs considerably faster in Tailwind v4 thanks to a native Rust engine compared to older versions, but it remains an additional build step that must be integrated into every pipeline, including a watch mode for local development. CSS Modules need a bundler with a matching loader, making them the most tightly bound to an existing JavaScript toolchain.

For IDE support: BEM class names are plain strings that need no special editor integration, Tailwind classes benefit heavily from autocompletion and inline preview via official plugins, and CSS Modules imports get TypeScript type checking if a type generator for .module.css files is additionally anchored in the team's CSS methodology.

7. Scaling in teams: onboarding, reviews, consistency

Onboarding speed is an often underestimated criterion when choosing a CSS methodology. New developers usually understand Utility First fastest, because the meaning of every class is directly readable from its name, without opening a separate stylesheet. BEM requires internalizing a naming convention that feels unfamiliar at first but can then be applied very consistently. CSS Modules require understanding the build step itself, which is an extra learning curve for developers without bundler experience.

In code reviews, Utility First shows its biggest practical advantage: a reviewer sees directly in the diff which visual changes were made, without jumping back and forth between the HTML file and a separate stylesheet. With BEM and CSS Modules, a change typically spreads across two files, which enlarges the review context but at the same time enforces a cleaner separation of structure and presentation, which some teams prefer on principle.

Consistency over time is, for all three variants of the CSS methodology, only as good as the enforced tooling chain. Stylelint rules for BEM, ESLint plugins for Tailwind class ordering and TypeScript types for CSS Modules imports are each the technical safeguard that prevents the convention from eroding over a multi year project as new team members contribute code without proper induction.

8. Bundle size and runtime performance

In terms of shipped CSS size, Utility First has a structural advantage: because every utility class exists exactly once project wide in the generated stylesheet, regardless of how often it is used in the markup, the CSS file grows with the number of distinct utility combinations, not with the number of components. A project with a hundred components that all use the same ten spacing and color utilities ends up with a smaller stylesheet than a hundred BEM components with their own, slightly diverging rules for spacing and color.

BEM stylesheets tend to grow over a project's lifetime because deleted components do not automatically remove their associated CSS rules, a linter can flag unused selectors but cannot always reliably tell whether a class is set dynamically via JavaScript. CSS Modules partially solve this problem because unused imports show up as build errors or warnings, but dead CSS within a still imported file also remains undetected unless an additional coverage tool is used.

9. CSS methodology compared head to head

The following table summarizes the decisive differences between the three variants of the CSS methodology, based on the criteria that most often decide the choice in practice.

No single entry in this table is an absolute argument, every criterion must be weighed against the concrete project situation. A legacy system without a bundler effectively rules out CSS Modules, a very small team without a dedicated frontend specialist often benefits more from the self explanatory nature of Utility First than a large team with established conventions that has worked productively with BEM for years.

10. Summary

Choosing the right CSS methodology between BEM, Utility First and CSS Modules is not a matter of taste, it is a decision with direct consequences for maintainability, onboarding and bundle size. BEM delivers flat specificity without a build dependency, but demands consistent self discipline across the team. Utility First reduces context switching and tends toward smaller stylesheets, but costs readability in raw markup without component abstraction. CSS Modules guarantee collision freedom at the language level, but are inseparably bound to a JavaScript build pipeline.

In practice, a deliberate hybrid is often the most pragmatic CSS methodology: utility classes for layout and spacing, named component classes for complex, recurring structures. What matters is that a team agrees on a combination early and secures it technically through linting rules, instead of letting the decision emerge implicitly from the differing habits of individual developers.

11. FAQ: BEM, Utility First and CSS Modules