BEM, Utility First und CSS Modules 2026 im Vergleich

1. Warum die CSS Methodik noch immer entscheidet

Eine CSS Methodik ist kein Selbstzweck, sondern eine bewusste Antwort auf ein strukturelles Problem der Sprache selbst. CSS kennt keinen nativen Namespace, keine eingebaute Kapselung und keine Garantie, dass eine Klasse in Datei A dieselbe Bedeutung hat wie in Datei B. Ohne Konvention wächst jedes mittelgroße Projekt zwangsläufig in Richtung globaler Kollisionen, unklarer Spezifität und eines Stylesheets, das niemand mehr vollständig löschen kann, weil niemand weiß, welche Regel wo noch gebraucht wird. Genau diese Unsicherheit ist der eigentliche Kostentreiber in gewachsenen Frontends, nicht die Anzahl der Zeilen CSS.

Die drei dominanten Antworten auf dieses Problem im Jahr 2026 sind BEM, Utility First und CSS Modules. Alle drei lösen Namenskollisionen und Kaskaden-Chaos, aber auf völlig unterschiedliche Weise: BEM über eine strenge Namenskonvention, Utility First über kleine, wiederverwendbare Klassen ohne semantische Bindung an eine Komponente, CSS Modules über automatisches Scoping zur Build-Zeit. Die Wahl der richtigen CSS Methodik hängt weniger von persönlichem Geschmack ab als von Teamgröße, Projektlaufzeit und der Frage, wie viel Build-Tooling ein Team bereit ist zu pflegen.

Dieser Artikel vergleicht alle drei Ansätze anhand konkreter Codebeispiele und liefert am Ende eine Entscheidungsmatrix. Ziel ist nicht, eine einzige CSS Methodik als Sieger zu küren, sondern die Kriterien offenzulegen, mit denen ein Team seine eigene Entscheidung treffen kann, statt einem Trend zu folgen, der zum eigenen Projektkontext nicht passt.

2. BEM: Block, Element, Modifier im Detail

BEM steht für Block, Element, Modifier und ist die älteste der drei hier besprochenen Ansätze, ursprünglich von Yandex entwickelt. Die Kernidee: jede Komponente ist ein Block, jedes Kindelement innerhalb dieses Blocks wird mit doppeltem Unterstrich angehängt, und Varianten werden mit doppeltem Bindestrich als Modifier markiert. Diese CSS Methodik macht die Struktur einer Komponente allein am Klassennamen ablesbar, ganz ohne die zugehörige HTML-Struktur zu sehen. Ein Entwickler, der card__title--highlighted liest, weiß sofort: das ist der Titel innerhalb des Blocks card, in der Modifier-Variante highlighted.

Der große Vorteil von BEM als CSS Methodik liegt in der flachen Spezifität. Weil jede Regel genau eine Klasse adressiert und niemals über Nachfahren-Selektoren wie .card .title arbeitet, bleibt die Spezifität über das gesamte Projekt konstant niedrig. Das verhindert den klassischen Spezifitätskrieg, bei dem Entwickler zunehmend spezifischere Selektoren oder !important einsetzen, um ältere Regeln zu überschreiben. BEM erzwingt diese Disziplin allerdings nur, wenn das ganze Team sie konsequent einhält, es gibt kein technisches Mittel, das einen Verstoß verhindert.

/* 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; } */

Der Nachteil zeigt sich bei tief verschachtelten Komponenten. Ein Block innerhalb eines Blocks führt schnell zu langen Klassennamen wie product-list__item__price--discounted, was BEM offiziell zwar ablehnt (Elemente gehören immer direkt zum Block, nicht zu Elementen von Elementen), in der Praxis aber trotzdem häufig vorkommt. Diese CSS Methodik verlangt außerdem, dass jede neue Komponente bewusst als eigener Block definiert wird, was Anfangsdisziplin, aber kaum Tooling-Unterstützung braucht, ein einfacher Linter für Klassennamen reicht meist aus.

3. Utility First: warum Tailwind das Styling verändert hat

Utility First als CSS Methodik kehrt die Logik von BEM fast vollständig um. Statt semantischer Klassen wie card__title verwendet man kleine, atomare Klassen wie text-xl font-bold mb-2, die jeweils genau eine CSS-Eigenschaft setzen. Tailwind CSS hat diesen Ansatz seit 2019 massentauglich gemacht, weil es die größte Schwäche früherer Utility-Frameworks, nämlich fehlende Design-Konsistenz durch beliebige Zahlenwerte, durch ein festes Spacing- und Farbsystem löst. Die Klasse p-4 bedeutet in jedem Projekt mit Standard-Konfiguration exakt denselben Wert, nicht mehr und nicht weniger.

Der entscheidende Vorteil dieser CSS Methodik: Entwickler verlassen das HTML nie, um ein Layout anzupassen. Es gibt kein separates Stylesheet, das parallel zur Komponente gepflegt werden muss, und damit auch kein Risiko von totem CSS, das nach dem Löschen einer Komponente im Stylesheet zurückbleibt. Tools wie der Tailwind-Compiler scannen das Markup und generieren nur die tatsächlich verwendeten Klassen, wodurch das ausgelieferte CSS in der Regel deutlich kleiner ist als ein handgeschriebenes BEM-Stylesheet mit ungenutzten Regeln aus früheren Projektphasen.

/* 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%);
}

Die häufigste Kritik an dieser CSS Methodik betrifft die Lesbarkeit des Markups. Eine Komponente mit zwanzig Utility-Klassen in einer einzigen class-Attribut-Zeile wirkt auf den ersten Blick unübersichtlich, besonders für Entwickler, die semantische Klassennamen gewohnt sind. In der Praxis relativiert sich das durch Komponenten-Extraktion in Frameworks wie React, Vue oder Blade-Templates, die Wiederholung ohnehin verhindern, wodurch die Utility-Liste nur an einer Stelle im Code sichtbar ist statt über viele Templates verstreut.

4. CSS Modules: lokaler Scope als Build-Feature

CSS Modules verfolgen als dritte CSS Methodik einen technischen statt konventionsbasierten Ansatz. Statt sich auf Namenskonventionen zu verlassen, generiert der Build-Prozess für jede lokal definierte Klasse einen eindeutigen, gehashten Bezeichner, etwa Card_title__x7f2a. Entwickler schreiben weiterhin gewöhnliches CSS mit gewöhnlichen Klassennamen wie .title, aber der Compiler garantiert, dass diese Klasse niemals mit einer gleichnamigen Klasse in einer anderen Datei kollidiert. Das macht diese CSS Methodik zur einzigen der drei Optionen, bei der Namenskollisionen technisch unmöglich statt nur unwahrscheinlich sind.

Der Import erfolgt direkt in der Komponentendatei, etwa import styles from './Card.module.css', und die Klasse wird dann als styles.title referenziert. Dieser explizite Import zwingt Entwickler dazu, jede verwendete Klasse tatsächlich zu importieren, tote Referenzen fallen beim Build sofort als Fehler auf. Composition über composes: base from './shared.module.css' erlaubt es, gemeinsame Basis-Stile ohne Vererbung im klassischen CSS-Sinn wiederzuverwenden.

/* 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;
*/

Der Nachteil dieser CSS Methodik ist die Abhängigkeit von einem Build-Schritt. Ohne Bundler wie Webpack, Vite oder Parcel funktionieren CSS Modules überhaupt nicht, was sie für Projekte ohne bestehende JavaScript-Build-Pipeline unattraktiv macht. Außerdem bleibt die generierte Klasse zur Laufzeit weiterhin eine gewöhnliche globale CSS-Klasse im DOM, die Kapselung existiert nur auf Ebene des Build-Tools und der Modul-Grenzen, nicht als Laufzeit-Isolation wie bei Shadow DOM.

5. Mischformen: Utility First mit BEM Komponenten kombinieren

In der Praxis arbeiten viele Teams nicht mit einer einzigen reinen CSS Methodik, sondern mit einer bewussten Mischung. Ein verbreitetes Muster: Utility-Klassen für Layout, Spacing und responsive Anpassungen direkt im Markup, während wiederkehrende, komplexe Komponenten wie ein Datepicker oder ein Rich-Text-Editor eine eigene, BEM-benannte Komponentenklasse bekommen. Diese Komponentenklasse kapselt interne Struktur, die sich schlecht in Utility-Klassen ausdrücken lässt, etwa Pseudo-Elemente, komplexe Selektoren für Zustände oder Animation-Keyframes.

Ein zweites Muster kombiniert Utility First mit CSS Modules: Utility-Klassen für generische, wiederholte Muster, CSS Modules für Komponenten mit sehr spezifischem, nicht wiederverwendbarem Styling. Die Entscheidung, wann eine Utility-Kombination in eine eigene Klasse extrahiert werden sollte, folgt meist einer einfachen Regel, nämlich sobald dieselbe Kombination von mehr als drei bis vier Utility-Klassen an mehr als drei Stellen im Code wiederholt wird. Tailwinds @apply-Direktive erlaubt genau diese Extraktion, ohne die Utility First Philosophie komplett zu verlassen.

/* 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 und Build-Pipeline Unterschiede

Die drei Ansätze unterscheiden sich massiv im benötigten Tooling. BEM als CSS Methodik braucht theoretisch überhaupt kein Build-Werkzeug, ein einfacher Stylelint mit einer BEM-spezifischen Plugin-Regel reicht, um Verstöße gegen die Namenskonvention zu erkennen. Das macht BEM attraktiv für Projekte ohne moderne JavaScript-Toolchain, etwa klassische serverseitig gerenderte Anwendungen oder Legacy-Systeme, in denen ein zusätzlicher Bundler politisch oder technisch schwer durchsetzbar wäre.

Utility First benötigt zwingend einen CSS-Compiler wie den Tailwind CLI oder das entsprechende PostCSS-Plugin, der das Markup nach verwendeten Klassen durchsucht. Dieser Scan-Schritt läuft in Tailwind v4 durch eine native Rust-Engine erheblich schneller als in älteren Versionen, bleibt aber ein zusätzlicher Build-Schritt, der in jede Pipeline integriert werden muss, inklusive Watch-Modus für die lokale Entwicklung. CSS Modules brauchen einen Bundler mit entsprechendem Loader, sind also am stärksten an eine bestehende JavaScript-Toolchain gebunden.

Für die IDE-Unterstützung gilt: BEM-Klassennamen sind reine Strings ohne spezielle Editor-Integration nötig, Tailwind-Klassen profitieren stark von Autovervollständigung und Inline-Vorschau via offizieller Plugins, und CSS-Modules-Importe erhalten TypeScript-Typprüfung, wenn zusätzlich ein Typgenerator für .module.css-Dateien in der CSS Methodik des Teams verankert ist.

7. Skalierung im Team: Onboarding, Reviews, Konsistenz

Onboarding-Geschwindigkeit ist ein oft unterschätztes Kriterium bei der Wahl einer CSS Methodik. Neue Entwickler verstehen Utility First in der Regel am schnellsten, weil die Bedeutung jeder Klasse direkt aus ihrem Namen ablesbar ist, ohne dass ein separates Stylesheet geöffnet werden muss. BEM erfordert das Verinnerlichen einer Namenskonvention, die zunächst ungewohnt wirkt, aber danach sehr konsistent angewendet werden kann. CSS Modules verlangen das Verständnis des Build-Schritts selbst, was für Entwickler ohne Bundler-Erfahrung eine zusätzliche Lernkurve bedeutet.

Bei Code-Reviews zeigt Utility First seinen größten praktischen Vorteil: Ein Reviewer sieht direkt im Diff, welche visuellen Änderungen vorgenommen wurden, ohne zwischen HTML-Datei und separatem Stylesheet hin und her zu springen. Bei BEM und CSS Modules verteilt sich eine Änderung typischerweise über zwei Dateien, was den Review-Kontext vergrößert, aber gleichzeitig eine sauberere Trennung von Struktur und Präsentation erzwingt, was manche Teams aus Prinzip bevorzugen.

Konsistenz über die Zeit ist bei allen drei Varianten der CSS Methodik nur so gut wie die durchgesetzte Tooling-Kette. Stylelint-Regeln für BEM, ESLint-Plugins für Tailwind-Klassenreihenfolge und TypeScript-Typen für CSS-Modules-Importe sind jeweils die technische Absicherung, die verhindert, dass die Konvention im Laufe eines mehrjährigen Projekts erodiert, wenn neue Teammitglieder ohne Einweisung Code beisteuern.

8. Bundle-Größe und Laufzeit-Performance

Bei der ausgelieferten CSS-Größe hat Utility First einen strukturellen Vorteil: Weil jede Utility-Klasse projektweit nur einmal im generierten Stylesheet existiert, unabhängig davon, wie oft sie im Markup verwendet wird, wächst die CSS-Datei mit der Anzahl unterschiedlicher Utility-Kombinationen, nicht mit der Anzahl der Komponenten. Ein Projekt mit hundert Komponenten, die alle dieselben zehn Spacing- und Farb-Utilities nutzen, erzeugt am Ende ein kleineres Stylesheet als hundert BEM-Komponenten mit jeweils eigenen, leicht abweichenden Regeln für Spacing und Farbe.

BEM-Stylesheets neigen dazu, über die Projektlaufzeit zu wachsen, weil gelöschte Komponenten ihre zugehörigen CSS-Regeln nicht automatisch mitnehmen, ein Linter kann ungenutzte Selektoren zwar melden, aber nicht immer zuverlässig erkennen, ob eine Klasse dynamisch per JavaScript gesetzt wird. CSS Modules lösen dieses Problem teilweise, weil ungenutzte Importe beim Build als Fehler oder Warnung auffallen, aber auch hier bleibt totes CSS innerhalb einer noch importierten Datei unentdeckt, wenn nicht zusätzlich ein Coverage-Tool eingesetzt wird.

9. CSS Methodik im direkten Vergleich

Die folgende Tabelle fasst die entscheidenden Unterschiede zwischen den drei Varianten der CSS Methodik zusammen, bezogen auf die Kriterien, die in der Praxis am häufigsten über die Wahl entscheiden.

Kein Eintrag in dieser Tabelle ist ein absolutes Argument, jedes Kriterium muss gegen die konkrete Projektsituation abgewogen werden. Ein Legacy-System ohne Bundler schließt CSS Modules faktisch aus, ein sehr kleines Team ohne dedizierten Frontend-Spezialisten profitiert oft stärker von der Selbsterklärbarkeit von Utility First als ein großes Team mit etablierten Konventionen, das mit BEM seit Jahren produktiv arbeitet.

10. Zusammenfassung

Die Wahl der richtigen CSS Methodik zwischen BEM, Utility First und CSS Modules ist keine Geschmacksfrage, sondern eine Entscheidung mit direkten Konsequenzen für Wartbarkeit, Onboarding und Bundle-Größe. BEM liefert flache Spezifität ohne Build-Abhängigkeit, verlangt aber konsequente Selbstdisziplin im Team. Utility First reduziert Kontextwechsel und tendiert zu kleineren Stylesheets, kostet aber Lesbarkeit im rohen Markup ohne Komponenten-Abstraktion. CSS Modules garantieren Kollisionsfreiheit auf Sprachebene, sind aber untrennbar an eine JavaScript-Build-Pipeline gebunden.

In der Praxis ist eine bewusste Mischform häufig die pragmatischste CSS Methodik: Utility-Klassen für Layout und Spacing, benannte Komponentenklassen für komplexe, wiederkehrende Strukturen. Entscheidend ist, dass ein Team sich früh auf eine Kombination einigt und diese über Linting-Regeln technisch absichert, statt die Entscheidung implizit durch unterschiedliche Gewohnheiten einzelner Entwickler treffen zu lassen.

11. FAQ: BEM, Utility First und CSS Modules