CSS kann klein und überschaubar sein, bis ein Projekt wächst. Spätestens wenn mehrere Teams an einer Codebase arbeiten, wenn Komponenten wiederverwendet werden sollen oder wenn Branding-Varianten entstehen, wird klar: Ohne eine klare Architektur wird CSS schnell chaotisch.

Dieses Türchen erklärt drei der wichtigsten Architekturansätze in modernen Projekten: BEM, ITCSS und CUBE CSS. Und vor allem: Wie sie sich unterscheiden, wo sie sich ergänzen und wie man sie bewusst einsetzt.

Warum braucht CSS überhaupt Architektur?

Die Antwort liegt in der Natur von CSS selbst. Es wirkt global. Jede Regel kann theoretisch jedes Element auf der Seite beeinflussen, und genau das wird zum Problem, sobald ein Projekt eine gewisse Größe überschreitet. Styles können kollidieren, ohne dass es offensichtlich ist. Eine vermeintlich lokale Änderung kann unerwartete Auswirkungen an völlig anderen Stellen der Anwendung haben. Was als spezifische Lösung für ein einzelnes Problem gedacht war, wird schnell zur Quelle globaler Konflikte.

Architektur ist dabei kein Selbstzweck und keine zusätzliche Komplexität um ihrer selbst willen. Sie schafft konkrete, messbare Vorteile im Entwicklungsalltag. Sie sorgt für Vorhersehbarkeit, so dass Entwickler wissen, wo sie Styles finden und wie sie neue hinzufügen, ohne Bestehendes zu brechen. Sie schafft Struktur, die es ermöglicht, auch in großen Codebases den Überblick zu behalten. Sie hilft, die Spezifität niedrig zu halten, sodass nicht jede neue Regel mit !important oder verschachtelten Selektoren arbeiten muss.

Klare Verantwortlichkeiten entstehen, wenn jeder Teil des Codes einen definierten Zweck hat und klar ist, wer wofür zuständig ist. Schließlich wird die Codebase deutlich besser skalierbar. Neue Features lassen sich hinzufügen, ohne dass das gesamte System neu gedacht werden muss. Gerade in wachsenden Teams, in denen mehrere Entwickler parallel an verschiedenen Features arbeiten, ist eine durchdachte CSS-Architektur nicht optional, sondern unverzichtbar.

1. BEM

BEM ist die Abkürzung von “Block, Element, Modifier” und vermutlich das bekannteste CSS-Architekturmodell. Es legt einen klaren Fokus auf Naming und die Struktur von Komponenten.

Grundprinzip:

.block {}
.block__element {}
.block--modifier {}

Beispiel:

.button {}
.button__icon {}
.button--primary {}

Vorteile von BEM

Der größte Vorteil von BEM liegt in der Klarheit der Namen. Ein Klassenname wie .card__title--featured ist sofort verständlich, selbst wenn man den Code zum ersten Mal sieht. Man erkennt auf den ersten Blick, dass es sich um einen Titel innerhalb einer Card handelt, der zusätzlich als „featured” markiert ist. Diese Selbstdokumentierung macht den Code wartbarer und reduziert die Einarbeitungszeit für neue Teammitglieder erheblich.

BEM vermeidet bewusst tiefe Selektorstrukturen. Statt .card .header .title zu schreiben, verwendet man einfach .card__title. Das hat den entscheidenden Vorteil, dass die Spezifität niedrig bleibt. Jede Klasse hat die gleiche Gewichtung, es gibt keine komplexen Kaskaden und keine Überraschungen beim Überschreiben von Styles. Das macht das System vorhersehbar und reduziert die Notwendigkeit von !important-Hacks.

Die Methodik ist stark komponentenorientiert, was perfekt zu modernen Frontend-Frameworks passt. Jeder Block ist in sich geschlossen, und die Abhängigkeiten sind explizit durch die Namenskonventionen sichtbar. Das erleichtert die Zusammenarbeit im Team erheblich, da Konflikte minimiert werden und jeder sofort versteht, welche Styles zu welcher Komponente gehören.

Typische Einsatzgebiete

BEM eignet sich besonders für klassische Websites, bei denen Komponenten klar definierbar sind und eine gewisse Wiederverwendung stattfindet, ohne dass das System zu komplex wird. In komponentenbasierten Systemen, wie z.B. React, Vue oder anderen Frameworks passt BEM hervorragend, da die Namenskonvention die Komponentengrenzen auch im CSS sichtbar macht. Auch in statischen oder semistatischen Designsystemen, bei denen Konsistenz wichtiger ist als extreme Flexibilität, hat sich BEM bewährt.

Nachteile

Die Kehrseite der expliziten Namen sind vergleichsweise lange Klassennamen. .navigation__list-item--active ist zwar eindeutig, aber auch verbose. In großen Projekten kann das HTML dadurch unübersichtlich werden. Manche Entwickler empfinden BEM als redundant, weil Informationen mehrfach kodiert werden und zwar einmal in der HTML-Struktur, einmal in den Klassennamen.

Der größte Nachteil ist die Notwendigkeit strikter Disziplin. BEM funktioniert nur, wenn alle Beteiligten die Konventionen konsequent einhalten. Ein einziger Entwickler, der beginnt, generische Selektoren oder verschachtelte Strukturen zu verwenden, kann die gesamte Architektur untergraben. Das erfordert Code-Reviews, klare Guidelines und eine gemeinsame Überzeugung im Team.

Moderne Unterstützung durch Tools: In der Praxis lassen sich BEM-Konventionen heute durch Linter wie Stylelint mit BEM-Plugins weitgehend automatisiert durchsetzen. Diese prüfen Syntax, Namenskonventionen und Spezifität und lassen sich in CI/CD-Pipelines integrieren. KI-Tools wie GitHub Copilot erkennen etablierte BEM-Patterns im Projekt und schlagen automatisch konforme Klassennamen vor. Das reduziert den manuellen Review-Aufwand erheblich, ersetzt jedoch nicht die konzeptionelle Entscheidung, wann etwas ein Block, Element oder Modifier sein sollte.

2. ITCSS

ITCSS ist die Abkürzung für “Inverted Triangle CSS” und ist ein Strukturmodell für ganze Stylesheet-Architekturen. Es definiert Ordnung, nicht Naming.

Die Schichten:

1. Settings (Variablen, Tokens)
2. Tools (Mixins, Functions)
3. Generic (Reset, Normalize)
4. Elements (HTML-Elementstyles)
5. Objects (strukturelle Patterns)
6. Components (komponentenspezifische Styles)
7. Utilities (kleine, hochspezifische Helfer)

Vorteile

Der entscheidende Vorteil von ITCSS liegt in der klaren, skalierbaren Projektstruktur. Die Aufteilung in Schichten zwingt dazu, über die Reichweite und Verantwortung jedes Styles nachzudenken. Settings und Tools sind reine Definitionen ohne Output, Generic und Elements setzen Grundlagen, Objects definieren wiederverwendbare Layout-Patterns, Components enthalten die spezifischen Styles, und Utilities bieten die letzten, hochspezifischen Anpassungen. Diese Hierarchie ist nicht willkürlich, sondern folgt dem Prinzip steigender Spezifität.

Wenn ITCSS korrekt angewandt wird, bleibt die Spezifität im gesamten System niedrig, weil jede Schicht nur das tut, was sie tun soll, ohne in die Verantwortung der nächsten Schicht einzugreifen. Die klare Trennung zwischen Low-Level-Styles, wie Resets und Element-Defaults und High-Level-Styles, wie komponentenspezifische Anpassungen macht das System wartbar und verständlich. Für große Teams und Designsysteme ist ITCSS ideal, weil verschiedene Teams an verschiedenen Schichten arbeiten können, ohne sich gegenseitig zu blockieren.

Nachteile

ITCSS setzt allerdings erhebliche Disziplin voraus. Es ist leicht, Styles in der falschen Schicht zu platzieren wie beispielsweise komponentenspezifische Regeln in der Objects-Schicht oder generische Resets in Components. Einmal etabliert, ist es schwer, diese Fehler wieder zu korrigieren, ohne das gesamte System zu refactoren.

Die Methodik erfordert zudem ein Build-System oder zumindest sehr klare Ordnerkonventionen und Import-Reihenfolgen. In Projekten ohne Build-Pipeline wird ITCSS schnell unpraktisch. Auch ist die Methodik weniger intuitiv als BEM. Während BEM-Namen selbsterklärend sind, muss man bei ITCSS erst das Konzept der Schichten verstanden haben, um zu wissen, wo man einen Style platziert.

Letzteres ist wohl auch der Grund, warum dieser Ansatz so selten in Projekten zu sehen ist. Die Lernkurve ist steil, und gerade juniorige Entwickler:innen sind schnell überfordert. Gerade in Teams mit wechselnder Besetzung oder unterschiedlichen Erfahrungslevel wird ITCSS oft nicht konsequent kommuniziert und schnell inkonsistent umgesetzt, was zu massiven Problemen führen kann.

Wann ITCSS sinnvoll ist

ITCSS entfaltet seine Stärken in großen Codebases, in denen die schiere Menge an CSS ohne klare Struktur schnell unüberschaubar wird. Wenn mehrere Teilteams parallel arbeiten, wie etwa ein Team für die Designsystem-Basis, ein anderes für Marketing-Komponenten und ein drittes für die Produkt-UI, bietet ITCSS klare Grenzen und Verantwortlichkeiten.

Besonders wertvoll ist ITCSS für Designsysteme, die über Jahre hinweg konsistent bleiben müssen. Die Schichtenarchitektur macht es einfach, grundlegende Änderungen wie etwa an Design-Tokens durchzuführen, ohne höhere Schichten zu beeinträchtigen. Auch in Projekten mit viel Legacy-CSS hilft ITCSS, Ordnung zu schaffen. Man kann schrittweise refactoren, indem man zunächst die unteren Schichten aufräumt und dann nach oben arbeitet.

3. CUBE CSS

CUBE CSS, oder ausgeschrieben “Composition, Utility, Block, Exception” ist moderner und leichter als BEM und ITCSS. Im Gegensatz zu BEM, das sich auf Naming konzentriert und ITCSS, das Struktur definiert, fokussiert sich CUBE CSS auf vier zentrale Konzepte:

1. Komposition als Grundlage für globale Design-Patterns
2. minimal spezifische Blocks für Komponenten
3. pragmatische Utilities für wiederkehrende Anpassungen
4. definierte Exceptions für bewusst markierte Sonderfälle

Diese vier Säulen arbeiten zusammen, um ein flexibles, wartbares System zu schaffen, das die Vorteile von Utility-First mit der Klarheit semantischer Komponenten verbindet.

Grundprinzip

Die vier Säulen von CUBE CSS bauen aufeinander auf und definieren jeweils unterschiedliche Verantwortlichkeiten im System:

Composition bildet die Grundlage des gesamten Systems. Hier werden globale Design-Patterns, typografische Scales, Spacing-Systeme und Layout-Logik definiert. Composition umfasst auch die Design-Tokens, CSS Custom Properties für Farben, Schriftgrößen, Abstände und andere wiederkehrende Werte. Diese Schicht ist framework-agnostisch und beschreibt die grundlegende visuelle Sprache des Projekts. Composition definiert das “Was” und “Wie” des Designs auf globaler Ebene, ohne sich um spezifische Komponenten zu kümmern.

Utility bietet Ein-Klassen-Helfer für häufig wiederkehrende Styling-Aufgaben. Klassen wie .mt-2 (margin-top), .flex (display: flex) oder .grid (display: grid) ermöglichen es, Layout und Spacing direkt im HTML anzupassen, ohne für jede Kleinigkeit eine neue Komponente oder Modifier erstellen zu müssen. Utilities sind bewusst hochspezifisch in ihrer Funktion. Sie sind eine Utility-Klasse macht genau eine Sache. Das macht sie extrem wiederverwendbar und reduziert die Notwendigkeit, CSS-Dateien zu bearbeiten, wenn man nur ein Spacing anpassen möchte.

Block bezeichnet die eigentlichen Komponenten wie z.B. Elemente wie Cards, Buttons oder Navigationen, die spezifische visuelle und funktionale Charakteristiken haben. Im Gegensatz zu BEM sind Blocks in CUBE CSS bewusst leichtgewichtig gehalten. Sie definieren nur das Wesentliche und verlassen sich für Layout und Spacing oft auf Composition und Utilities. Ein Block hat klare Styles, aber minimale Spezifität. Es gibt keine tief verschachtelten Selektoren oder komplexe Override-Logik. Blocks nutzen die Design-Tokens aus der Composition-Schicht und kombinieren sich mit Utilities für Flexibilität.

Exception markiert bewusste Abweichungen vom Standard. Sie sind Sonderfälle, die aus guten Gründen existieren. Exceptions werden explizit benannt (z. B. .is-error, .has-icon, .u-force-wrap) und signalisieren. Hier passiert etwas Außergewöhnliches. Das macht den Code selbstdokumentierend und verhindert, dass Sonderfälle stillschweigend in Blocks eingebaut werden. Eine Exception ist temporär und kontextabhängig, das heißt sie sollte nicht die Regel werden. Durch die explizite Benennung bleibt der Code wartbar, weil klar ist, wo bewusste Abweichungen existieren.

Beispiel:

/* Utility */
.u-text-center { text-align: center; }

/* Block */
.card {
  padding: var(--space-m);
  border-radius: var(--radius-m);
}

/* Exception */
.card.is-error {
  border-color: var(--error);
}

Vorteile

CUBE CSS nutzt Utilities bewusst, um die Spezifität niedrig zu halten. Statt komplexe Selektoren zu schreiben, kombiniert man einfache Ein-Zweck-Klassen wie .flex oder .gap-2 mit leichtgewichtigen Block-Styles. Das Ergebnis ist CSS, das weniger Konflikte produziert und einfacher zu überschreiben ist, wenn nötig.

Die Methodik ist sehr flexibel und passt sich verschiedenen Projektgrößen an. Sie ist modern und leichtgewichtig. Es gibt keine starren Regeln wie bei BEM, keine komplexe Schichtenhierarchie wie bei ITCSS. Stattdessen fördert CUBE CSS einen pragmatischen Ansatz. Composition für globale Patterns, Utilities für schnelle Anpassungen, Blocks für echte Komponenten und Exceptions nur da, wo es wirklich nötig ist. Das macht modulare Systeme einfacher, weil man nicht für jeden Anwendungsfall eine neue Komponente bauen muss.

Nachteile

CUBE CSS setzt konzeptionelle Klarheit voraus. Man muss verstehen, wann etwas eine Composition, eine Utility, ein Block oder eine Exception ist. Diese Unterscheidung ist nicht immer offensichtlich und verschiedene Entwickler können zu unterschiedlichen Schlüssen kommen. Das kann zu Inkonsistenzen führen, wenn nicht klar kommuniziert wird, welche Konventionen gelten.

In Teams ohne fundiertes CSS-Know-how kann CUBE CSS manchmal ungewohnt wirken. Während BEM durch seine expliziten Namen selbsterklärend ist, erfordert CUBE CSS ein tieferes Verständnis davon, wie CSS funktioniert und wie man Spezifität und Komposition nutzt. Das Naming ist zudem weniger streng als bei BEM. Es gibt kein festes Schema wie block__element--modifier, was Freiheit bedeutet, aber auch Raum für Inkonsistenz lässt.

Ideal Einsatz

CUBE CSS ist ideal für moderne Komponentenbibliotheken, die sowohl in traditionellen Projekten als auch in Framework-basierten Anwendungen funktionieren sollen. Die Kombination aus Utilities und leichtgewichtigen Blocks macht das System extrem anpassungsfähig.

Teams, die Utility-Klassen bevorzugen wie etwa weil sie bereits mit Tailwind oder ähnlichen Frameworks gearbeitet haben, finden in CUBE CSS einen strukturierten Mittelweg. Es bietet die Flexibilität von Utility-First, ohne die semantische Klarheit von Komponenten aufzugeben.

Besonders wertvoll ist CUBE CSS für Projekte, die sowohl pragmatisch als auch strukturiert sein sollen. Es ist kein Alles-oder-Nichts-Ansatz wie BEM, sondern erlaubt es, je nach Situation den passenden Stil zu wählen: Utilities für einfache Anpassungen, Blocks für wiederverwendbare Komponenten, Exceptions für die wenigen Sonderfälle, die jedes Projekt hat.

Wie ergänzen sich die Ansätze?

Die drei Architekturansätze sind keine konkurrierenden Philosophien, sondern lösen unterschiedliche Probleme.

BEM löst das Problem des Namings. Es gibt eine klare Antwort auf die Frage, wie man Komponenten und ihre Teile benennt.

ITCSS löst das Problem der Struktur. Es definiert, wie man Styles in Schichten organisiert und dabei die Spezifität kontrolliert.

CUBE CSS löst das Problem der Komplexität in modularen Systemen. Es bietet einen Mittelweg zwischen semantischen Komponenten und pragmatischen Utilities.

Diese unterschiedlichen Schwerpunkte machen die Ansätze kompatibel. In der Praxis enden viele große Teams bei einer Hybridlösung, die die Stärken aller drei Ansätze kombiniert. Man nutzt ITCSS für die grundlegende Struktur der Codebase, die Aufteilung in Settings, Tools, Generic, Elements, Objects, Components und Utilities gibt eine klare Ordnung vor. Innerhalb der Components-Schicht verwendet man BEM für konsistentes, selbsterklärendes Naming. Und für Layout-Anpassungen, Spacing und andere wiederkehrende Patterns nutzt man Utilities, die von CUBE CSS inspiriert sind oder direkt aus Tailwind übernommen werden.

Ein konkretes Beispiel für diese Hybridlösung sieht so aus. In der Settings-Schicht werden CSS Custom Properties für alle Design-Tokens definiert. Konkret wären das Farben, Schriftgrößen, Abstände, Border-Radien. In der Utilities-Schicht entstehen Abstraktionen für Margin, Padding, Gap und andere häufig genutzte Spacing-Eigenschaften. In der Components-Schicht leben BEM-Komponenten wie .card, .card__header, .card__title--featured, die auf die Design-Tokens zugreifen. Die gesamte Architektur folgt den ITCSS-Schichten, sodass klar ist, in welcher Reihenfolge die Dateien geladen werden und wie die Spezifität steigt.

Dieses Setup ist in Enterprise-Designsystemen heute sehr verbreitet, weil es die Vorteile aller drei Ansätze vereint. Klare Struktur durch ITCSS, verständliches Naming durch BEM und pragmatische Flexibilität durch Utilities. Es ist kein theoretisches Konstrukt, sondern eine praxiserprobte Lösung für reale, komplexe Projekte.

Weitere relevante Ansätze im Überblick

Die CSS-Architekturlandschaft ist breiter als die drei hier ausführlich behandelten Ansätze. Verschiedene Werkzeuge und Methoden haben sich je nach Technologie-Stack und Projektanforderungen etabliert. Während BEM, ITCSS und CUBE CSS framework-agnostische Prinzipien darstellen, gibt es weitere Ansätze, die besonders in bestimmten Ökosystemen verbreitet sind.

CSS Modules

CSS Modules ist ein Build-Tool-basierter Ansatz, der Styles automatisch auf Komponentenebene isoliert. Klassennamen werden beim Build-Prozess in eindeutige Hashes umgewandelt (z. B. .button wird zu .button_3x7sK), wodurch Namenskollisionen technisch unmöglich werden. Das ist besonders in React- und Vue-Projekten verbreitet, wo jede Komponente ihre eigene CSS-Datei hat. Der Vorteil liegt in der automatischen Isolation. Man muss sich keine Gedanken über globale Namenskonflikte machen. Der Nachteil ist die Abhängigkeit von Build-Tools und die Tatsache, dass die generierten Klassennamen nicht mehr selbsterklärend sind. CSS Modules funktioniert gut in Kombination mit BEM-ähnlichen Namenskonventionen innerhalb der Komponenten.

Utility-First und Tailwind CSS

Utility-First ist keine Architektur im klassischen Sinne, sondern eine Philosophie. Statt semantische Komponentenklassen zu schreiben, kombiniert man atomare Utility-Klassen direkt im HTML. Tailwind CSS ist der prominenteste Vertreter dieses Ansatzes. Klassen wie flex, pt-4, bg-blue-500 oder hover:opacity-75 werden direkt im Markup verwendet. Das beschleunigt die Entwicklung erheblich, da man nicht zwischen HTML und CSS hin- und herwechseln muss.

Der Ansatz ist allerdings kontrovers. Befürworter schätzen die Geschwindigkeit und die enge Kopplung von Styles und Markup. Kritiker bemängeln die “unübersichtlichen” HTML-Dateien und die Vermischung von Präsentation und Struktur. In der Praxis zeigt sich, dass Utility-First besonders gut für Prototyping, Marketing-Seiten und kleine bis mittlere Projekte funktioniert. In sehr großen, langlebigen Designsystemen wird es oft mit komponentenbasierten Ansätzen kombiniert wie beispielsweise Utilities für Layout und Spacing, semantische Komponenten für komplexe UI-Elemente.

CSS-in-JS und Styled Components

CSS-in-JS schreibt Styles direkt in JavaScript-Code, oft als Template Literals. Styled Components, Emotion und ähnliche Libraries sind besonders im React-Ökosystem verbreitet.

Der Vorteil: Styles können dynamisch auf Props reagieren, und es gibt keine separaten CSS-Dateien mehr. TypeScript-Support und automatisches Critical-CSS-Extraction sind weitere Pluspunkte.

Die Nachteile: Runtime-Overhead - Styles werden zur Laufzeit generiert und injizier - , größere Bundle-Sizes und die Tatsache, dass CSS nicht mehr in reinem CSS geschrieben wird. CSS-in-JS ist stark framework-abhängig und macht Sinn, wenn man ohnehin tief im React-Ökosystem arbeitet und die Vorteile der JavaScript-Integration nutzen möchte. Für framework-agnostische Designsysteme ist es weniger geeignet.

Historische Grundlagen: OOCSS und SMACSS

Bevor BEM, ITCSS und CUBE CSS populär wurden, prägten OOCSS (Object-Oriented CSS) und SMACSS (Scalable and Modular Architecture for CSS) das Denken über CSS-Architektur. OOCSS führte die Idee ein, Struktur und Skin zu trennen und wiederverwendbare “Objekte” zu schaffen. SMACSS definierte Kategorien wie Base, Layout, Module, State und Theme. Beide Ansätze sind heute weniger direkt in Projekten zu finden, haben aber BEM, ITCSS und moderne Architekturen stark beeinflusst. Wer die Grundlagen verstehen will, sollte beide kennen. In der Praxis werden heute jedoch eher ihre Weiterentwicklungen eingesetzt.

Ein mögliches Beispiel aus einem Projekt

Ein Team arbeitete an einer UI-Bibliothek mit über 120 Komponenten, die in mehreren Produkten eingesetzt wurde. Das ursprüngliche CSS war historisch gewachsen und zeigte alle typischen Probleme einer ungeplanten Architektur. Es war hoch spezifisch, mit verschachtelten Selektoren und !important-Kaskaden, die entstanden waren, weil Entwickler nicht mehr wussten, wie sie Styles sicher überschreiben konnten. Die Struktur war schlecht, Dateien enthielten willkürliche Mixe aus globalen Resets, Komponenten-Styles und Utilities. Das System war voller Overrides. Jede neue Anforderung führte dazu, dass bestehende Styles mit noch spezifischeren Regeln überschrieben wurden. Das Ergebnis war unübersichtlich und schwer zu warten.

Das Team entschied sich für eine schrittweise Umstellung auf eine hybride Architektur. Zunächst wurde ITCSS als Strukturmodell eingeführt. Eine klare Ordnerstruktur mit Settings für Design-Tokens, Tools für Sass-Mixins, Generic für Resets, Elements für HTML-Element-Defaults, Objects für Layout-Patterns, Components für die eigentlichen Komponenten und Utilities für Helferklassen. Parallel wurde für alle Komponenten BEM-Naming eingeführt, was die Lesbarkeit und Wartbarkeit sofort verbesserte. CUBE CSS Utilities wurden für wiederkehrende Layout-, Spacing- und typografische Anpassungen genutzt, was die Notwendigkeit, für jede Kleinigkeit eine neue Komponenten-Variante zu bauen, eliminierte. Custom Properties wurden konsequent für alle Design-Tokens verwendet, was Theming und globale Anpassungen erheblich vereinfachte.

Das Ergebnis war beeindruckend. Die Gesamtmenge an CSS reduzierte sich um etwa 40 Prozent, weil Redundanzen eliminiert und Utilities wiederverwendet wurden. Merge-Konflikte wurden deutlich seltener, da die klare Struktur es jedem ermöglichte, zu wissen, wo neue Styles hingehören. Die Zusammenarbeit zwischen Design und Engineering verbesserte sich, weil die Design-Tokens in der Settings-Schicht eine gemeinsame Sprache boten. Und die Entwicklung neuer Komponenten wurde schneller, weil das Team auf etablierte Patterns und Utilities zurückgreifen konnte, statt jedes Mal von vorne anzufangen.

Wann welchen Ansatz wählen?

Wähle BEM, wenn:

BEM ist die richtige Wahl, wenn Komponenten im Zentrum deines Projekts stehen und du eine klare, selbsterklärende Namenskonvention brauchst. Wenn du in einem Team arbeitest, in dem nicht alle tiefgreifende CSS-Kenntnisse haben, hilft BEM durch seine Explizitheit. Ein Blick auf den Klassennamen reicht, um zu verstehen, was ein Element tut und wo es hingehört.

Naming-Konsistenz ist bei BEM unverzichtbar. Wenn dein Team bereit ist, diese Konsistenz durchzusetzen, zahlt sich das aus. BEM funktioniert besonders gut in mittelgroßen Teams, bei denen genug Entwickler beteiligt sind, dass Struktur notwendig ist, aber nicht so viele, dass ein komplexeres System wie ITCSS gerechtfertigt wäre. Wenn dein Projekt eine überschaubare Anzahl an Komponenten hat und du keine extreme Skalierung erwartest, bietet BEM genau die richtige Balance zwischen Struktur und Einfachheit.

Wähle ITCSS, wenn:

ITCSS ist die richtige Wahl für große Projekte, bei denen die schiere Menge an CSS ohne klare Struktur unbeherrschbar wird. Wenn mehrere Teams parallel an verschiedenen Teilen der Anwendung arbeiten wie etwa ein Designsystem-Team, ein Marketing-Team und mehrere Feature-Teams, bietet ITCSS klare Schichten und Verantwortlichkeiten, die Konflikte minimieren.

Wenn Styles global verteilt sind und nicht nur in isolierten Komponenten leben, hilft ITCSS dabei, Ordnung zu schaffen und die Spezifität zu kontrollieren. Besonders wertvoll ist ITCSS, wenn ein Designsystem existiert, das über Jahre hinweg gepflegt werden muss. Die Schichtenhierarchie macht es möglich, grundlegende Änderungen an Design-Tokens oder Resets durchzuführen, ohne Komponenten-Styles zu beeinträchtigen. ITCSS ist kein Quick-Win, sondern eine langfristige Investition in die Architektur.

Wähle CUBE CSS, wenn:

CUBE CSS ist ideal, wenn du moderne, flexible Komponenten baust und dabei pragmatisch bleiben willst. Wenn Utility-first für dein Team Sinn ergibt, etwa weil ihr bereits mit Tailwind experimentiert habt oder die Idee wiederverwendbarer Ein-Zweck-Klassen schätzt, bietet CUBE CSS einen strukturierten Rahmen, ohne die semantische Klarheit von Komponenten aufzugeben.

Wenn du wenig Spezifität möchtest und Konflikte durch intelligente Komposition und Utilities vermeiden willst, ist CUBE CSS eine hervorragende Wahl. Es passt zu Teams, die weder die Starrheit von BEM noch die Komplexität von ITCSS wollen, aber dennoch eine erkennbare Architektur brauchen. CUBE CSS ist besonders wertvoll, wenn du pragmatisch arbeiten willst. Du wählst für jede Situation den passenden Ansatz, statt dich an ein starres Regelwerk zu halten.

Fazit

CSS-Architektur ist die Grundlage für langfristige Wartbarkeit. Ob BEM, ITCSS oder CUBE CSS, wichtig ist, dass man einen Ansatz bewusst wählt, ihn konsequent umsetzt und ihn nicht als starres Regelwerk, sondern als Leitlinie versteht.