CSS-in-JS: Typische Anti-Patterns und wann es sich nicht lohnt

CSS-in-JS hat die Frontend-Welt polarisiert. Die einen schwören auf die Typsicherheit und Kapselung, die anderen sehen darin eine Lösung für Probleme, die man sich erst erschaffen muss.

Dieser Artikel ist keine Polemik. Es geht um eine sachliche Analyse: Welche Anti-Patterns entstehen durch CSS-in-JS, wann lohnt es sich trotzdem – und wie schneiden Alternativen wie Tailwind, StyleX oder klassisches CSS in modernen Frameworks wie Astro ab?

Die sechs typischen Anti-Patterns

1. Styling wird Teil der Business-Logik

Das Problem: Wenn Styles in JavaScript leben, verschwimmt die Grenze zwischen Darstellung und Verhalten. Styles reagieren auf Daten, Flags, Conditions. UI-Logik verteilt sich auf Render-Code und Style-Definitionen.

// Wo endet Logik, wo beginnt Styling?
const Button = ({ isLoading, variant, size, disabled }) => {
  const styles = css`
    background: ${isLoading ? 'gray' : variant === 'primary' ? 'blue' : 'white'};
    opacity: ${disabled ? 0.5 : 1};
    padding: ${size === 'large' ? '16px 32px' : '8px 16px'};
  `;
  return <button className={styles}>...</button>;
};

Die Folge: Was eigentlich rein visuell ist, wird schwer testbar und schlechter verständlich. CSS verliert seine Rolle als deklarative Beschreibung.

2. Design-Entscheidungen zur Laufzeit

Das Problem: CSS-in-JS lädt dazu ein, Werte dynamisch zu berechnen. Abstände, Farben, Größen entstehen „on the fly”. Design-Tokens werden umgangen oder neu erfunden.

// Jede Komponente erfindet ihre eigenen Regeln
const spacing = props.compact ? 8 : props.size * 4;
const color = darken(theme.primary, props.depth * 0.1);

Die Folge: Kein stabiles Design-System mehr, sondern implizite Regeln im Code. Konsistenz hängt von Disziplin ab – nicht von Technik.

3. Verlust der Stärke von CSS als Sprache

Das Problem: CSS ist gut in Dingen, die CSS-in-JS oft aushebelt:

Kaskade: Styles vererben sich natürlich
Media Queries: Responsive Design ohne JavaScript
Feature Queries: Progressive Enhancement
Container Queries: Komponenten-relatives Styling
Vererbung: inherit, currentColor, relative Einheiten

CSS-in-JS kapselt Styles komponentenweise. Diese Mechaniken werden bewusst oder unbewusst ausgehebelt.

Die Folge: Man bekämpft Probleme mit mehr Code und mehr Tooling, die CSS seit Jahren elegant löst.

4. Tooling-Lock-in

Das Problem: CSS-in-JS funktioniert selten „einfach so”:

Babel-Plugins oder SWC-Transformationen
Framework-spezifische Bindungen
Spezielle Runtime-APIs
Build-Tool-Konfiguration

Die Folge: Styles sind nicht mehr portabel. Ein Framework- oder Build-Wechsel wird zur Design-Migration. Wer von styled-components zu Emotion wechselt, refaktoriert. Wer zu einem anderen Framework geht, fängt oft von vorne an.

5. Debugging wird unnötig komplex

Das Problem: Styles existieren nicht mehr als klare, überprüfbare Artefakte:

Generierte Klassennamen: .sc-bdVaJa, .css-1a2b3c
Build-Artefakte statt Source-CSS
Mapping zwischen JS, Build und DOM nötig

Die Folge: Der einfache Blick in die DevTools reicht nicht mehr. Styling wird indirekt. Um zu verstehen, warum ein Element so aussieht, muss man durch mehrere Abstraktionsebenen navigieren.

6. Performance-Risiken als Standard

Das Problem: Auch „Zero-Runtime”-Ansätze sehen sauber aus, bringen aber:

Längere Build-Zeiten
Komplexere Pipelines
Größere mentale Last im Team
Potenzielle Hydration-Probleme bei SSR

Die Folge: Performance-Optimierung wird ein Architekturthema – statt eine Eigenschaft von CSS zu bleiben.

Der große Vergleich: CSS-in-JS vs. Tailwind vs. StyleX

Übersicht

Aspekt	CSS-in-JS (Emotion, styled-components)	Tailwind CSS	StyleX
Runtime	Ja (außer Linaria)	Nein	Nein
Typsicherheit	Mit TypeScript möglich	Begrenzt (Plugins)	Stark (Meta-Standard)
Bundle-Size	Variabel, oft groß	Nur genutzte Klassen	Minimal, dedupliziert
Lernkurve	Mittel	Niedrig-Mittel	Mittel-Hoch
Portabilität	Gering	Hoch	Mittel
Design-System-Kontrolle	Frei (zu frei?)	Token-basiert	Strikt
Debugging	Komplex	Einfach	Einfach
SSR-Kompatibilität	Aufwendig	Trivial	Gut

Tailwind CSS: Utility-First als Gegenentwurf

Philosophie: Statt Styles in JavaScript zu schreiben, nutzt Tailwind vordefinierte Utility-Klassen. Das Design-System ist in der Konfiguration verankert – nicht im Komponenten-Code.

<!-- Tailwind: Deklarativ, portabel, debugbar -->
<button class="bg-blue-500 hover:bg-blue-600 px-4 py-2 rounded-lg text-white">
  Click me
</button>

Vorteile gegenüber CSS-in-JS:

Kein Runtime-Overhead
Perfekte SSR-Kompatibilität
DevTools zeigen echte Klassen
Design-Tokens zentral konfiguriert
Framework-agnostisch

Nachteile:

Lange Klassenlisten im Markup
Keine echte Typsicherheit
Semantik der Klassen muss gelernt werden

Wann Tailwind besser passt:

Projekte mit klarem Design-System
Teams, die schnell iterieren
Static Sites und SSR-Frameworks
Wenn Portabilität wichtig ist

StyleX: Metas Antwort auf CSS-in-JS-Probleme

Philosophie: StyleX ist Metas internes Styling-System, jetzt Open Source. Es kombiniert die Vorteile von CSS-in-JS (Kapselung, Typsicherheit) mit Zero-Runtime und strikter Deduplizierung.

// StyleX: Typsicher, aber kompiliert zu atomarem CSS
import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  button: {
    backgroundColor: 'blue',
    padding: '8px 16px',
    borderRadius: '8px',
  },
});

<button {...stylex.props(styles.button)}>Click me</button>

Vorteile gegenüber klassischem CSS-in-JS:

Kompiliert zu atomarem CSS (wie Tailwind)
Keine Runtime
Strikte Typsicherheit
Automatische Deduplizierung
Deterministische Spezifität

Nachteile:

Meta-Ökosystem-Bindung
Steile Lernkurve
Weniger Community-Support als Tailwind
Build-Tooling erforderlich

Wann StyleX besser passt:

Sehr große Codebases
Teams, die TypeScript konsequent nutzen
Wenn strikte Design-System-Kontrolle Pflicht ist
React-lastige Projekte

Einordnung für moderne Static-Site-Frameworks

Astro: CSS wie es sein sollte

Astro ist ein Paradebeispiel dafür, wie moderne Frameworks CSS wieder ernst nehmen.

Scoped Styles out of the box:

---
// Astro-Komponente
---
<button class="btn">Click me</button>

<style>
  .btn {
    background: var(--color-primary);
    padding: var(--spacing-2) var(--spacing-4);
    border-radius: var(--radius-md);
  }
</style>

Warum Astro CSS-in-JS überflüssig macht:

Automatisches Scoping: Styles sind komponentenbezogen, ohne Runtime
Echtes CSS: Media Queries, Container Queries, Cascade – alles funktioniert
Zero JavaScript: Styles sind Build-Artefakte, nicht Runtime-Code
Tailwind-Integration: Erstklassiger Support, wenn gewünscht
Design-Tokens: CSS Custom Properties als natives System

Die Empfehlung für Astro-Projekte:

Ansatz	Empfehlung
Scoped `<style>`	Default für komponentenspezifische Styles
Global CSS	Design-Tokens, Reset, Typography
Tailwind	Utility-Klassen für schnelles Prototyping
CSS-in-JS	Nicht empfohlen – kein Vorteil, nur Overhead

Andere Static-First-Frameworks

Next.js (App Router):

CSS Modules als Default
Tailwind offiziell empfohlen
CSS-in-JS möglich, aber mit SSR-Komplexität

SvelteKit:

Scoped Styles eingebaut
Kein Bedarf für CSS-in-JS
Tailwind funktioniert hervorragend

Nuxt:

Vue Scoped Styles
UnoCSS/Tailwind als Utility-Option
CSS-in-JS unüblich

Gemeinsamer Trend: Moderne Frameworks liefern Scoping-Mechanismen, die CSS-in-JS obsolet machen – zumindest für die meisten Projekte.

Fairness-Abschnitt: Wann CSS-in-JS Sinn ergibt

Es wäre unfair, CSS-in-JS pauschal abzulehnen. Es gibt legitime Anwendungsfälle:

Große Organisationen mit besonderen Anforderungen

Massive Codebases: Tausende Komponenten, hunderte Entwickler
Strikte Typ-Kontrolle: TypeScript als einzige Wahrheit
Design-System-Governance: Zentrale Kontrolle über erlaubte Styles
Monorepo-Konsistenz: Styles müssen über Packages hinweg deterministisch sein

Spezifische technische Anforderungen

Theming zur Laufzeit: Wenn Themes nicht zur Build-Zeit bekannt sind
Dynamische Styles: Werte, die wirklich von User-Input abhängen
White-Label-Produkte: Kunden definieren Styles über APIs

Aber: Diese Probleme betreffen die Minderheit

Die meisten Projekte haben:

Unter 100 Komponenten
Ein festes Design-System
Build-Time-Themes
Teams unter 10 Entwicklern

Für diese Projekte erkauft man sich mit CSS-in-JS Komplexität ohne echten Gegenwert.

Die Entscheidungshilfe

Wähle klassisches CSS / CSS Modules, wenn:

Portabilität wichtig ist
Das Team CSS beherrscht
SSR/Static-Site im Einsatz ist
Langzeit-Wartung Priorität hat

Wähle Tailwind, wenn:

Schnelle Iteration wichtig ist
Ein klares Design-System existiert
Das Team Utility-First akzeptiert
Konsistenz über Komponenten hinweg Priorität hat

Wähle StyleX, wenn:

TypeScript-Strenge gewünscht ist
Die Codebase sehr groß ist
Meta-Ökosystem kein Problem ist
Atomares CSS mit Typsicherheit das Ziel ist

Wähle CSS-in-JS (Emotion, styled-components), wenn:

Legacy-Gründe es erfordern
Runtime-Theming unverzichtbar ist
Das Team bereits investiert hat
Die Organisation entsprechende Governance hat

Die Kernfrage: Effizienz oder Abhängigkeit?

CSS-in-JS ist kein technischer Fortschritt für Styling an sich. Es ist ein Organisations-Werkzeug für sehr große Teams mit spezifischen Governance-Anforderungen.

Für die meisten Projekte gilt eine einfache Wahrheit:

Je näher Styles an JavaScript rücken, desto weiter entfernen sie sich von dem, was CSS gut kann.

Die gute Nachricht: Moderne Alternativen existieren. Tailwind gibt Struktur ohne Runtime. StyleX bringt Typsicherheit ohne Overhead. Astro und andere Frameworks liefern Scoping ohne Magie.

Die Frage ist nicht „CSS-in-JS oder nicht?”. Die Frage ist: Welches Problem löst du wirklich – und ist CSS-in-JS die einfachste Lösung dafür?

In den meisten Fällen lautet die Antwort: Nein.