Panda CSS vs. StyleX

Panda CSS und StyleX kompilieren Styles beide zur Build-Zeit zu statischem atomarem CSS und liefern keine Styling-Runtime an den Browser aus. Was sie unterscheidet, ist das Problem, für dessen Lösung sie jeweils entwickelt wurden: Panda setzt ein Designsystem durch, und StyleX verhindert, dass die Styles einer Komponente mit denen einer anderen kollidieren.

Beide landen auf der Shortlist, wenn ein Team von styled-components oder Emotion wegmigrieren möchte, ohne auf typisierte, kolokalisierte Styles zu verzichten, und die beiden READMEs klingen nahezu identisch. Dieser Artikel arbeitet den einen strukturellen Unterschied zwischen ihnen heraus, zeigt denselben Button in beiden Varianten und verfolgt, wie sich dieser Unterschied auf Workflow, Theming und dynamische Werte auswirkt. Einen breiteren Überblick bietet der Stand von CSS-in-JS im Jahr 2026.

Was Panda CSS und StyleX gemeinsam haben

Panda CSS und StyleX sind beide Zero-Runtime-CSS-in-JS-Bibliotheken. Sie schreiben Style-Objekte in TypeScript, ein Build-Schritt extrahiert sie, und der Browser erhält ein einfaches Stylesheet aus atomaren Klassen mit jeweils nur einem Zweck. Runtime-Bibliotheken wie styled-components und Emotion funktionieren anders: Sie erzeugen Styles während des Renderns per JavaScript und injizieren sie. Panda und StyleX erledigen diese gesamte Arbeit, bevor der Code ausgeliefert wird. Die ältere Variante derselben Unterscheidung behandelt Linaria vs. styled-components.

Da die Ausgabe statisches CSS ist, benötigt keine der beiden Bibliotheken einen Context-Provider oder einen Style-Injector zur Render-Zeit. Deshalb funktionieren beide mit React Server Components: Während eines Server- oder Client-Renders wird kein Styling-Code ausgeführt. In der atomaren Ausgabe setzt jede Klasse genau eine Eigenschaft, sodass die Größe des Stylesheets mit der Anzahl eindeutiger Deklarationen wächst und nicht mit der Anzahl der Komponenten.

Panda CSS: Designsystem zuerst

Panda CSS behandelt das Designsystem als Single Source of Truth. In panda.config.ts definierte Tokens steuern einen Codegenerierungsschritt, der typisierte Helper wie css(), cva() und styled() für den Rest der Codebasis erzeugt. Panda stammt vom Team hinter Chakra UI, und der Hintergrund als Komponentenbibliothek ist deutlich zu erkennen.

Der Befehl panda codegen schreibt ein Verzeichnis styled-system/ in Ihr Projekt. Komponenten importieren ihre Helper aus diesem Verzeichnis, und die darin enthaltenen Typen werden aus Ihren Tokens generiert. Ist brand ein Farb-Token, wird bg: 'brand' per Autovervollständigung vorgeschlagen. Mit der Konfigurationsoption strictTokens wird ein roher Hex-Wert zum Typfehler.

Recipes machen daraus Komponenten-APIs. cva() nimmt einen base-Style, benannte variants und defaultVariants entgegen und gibt eine Funktion zurück, die Varianten-Props auf Klassennamen abbildet. Das Designsystem legt fest, welche Optionen existieren, und Komponenten wählen aus dieser Liste.

StyleX: Kollisionen zuerst

StyleX betrachtet Style-Kollisionen als das Kernproblem. Jede Komponente definiert ihre eigenen Style-Objekte mit stylex.create(), und stylex.props() führt sie deterministisch zusammen: Setzen zwei Styles dieselbe Eigenschaft, gewinnt der zuletzt übergebene. Die Reihenfolge im Stylesheet und die Spezifität von Selektoren spielen keine Rolle. StyleX ist ein Open-Source-Projekt von Meta und bildet die Styling-Schicht unter Designsystemen wie Astryx.

const styles = stylex.create({
  a: { color: 'red' },
  b: { color: 'blue' },
})
stylex.props(styles.a, styles.b) // blue
stylex.props(styles.b, styles.a) // red

Die Merge-Regeln von StyleX gelten auch für Shorthands. Thinking in StyleX erläutert, dass ein Konflikt zwischen einer Shorthand- und einer Longhand-Eigenschaft immer gleich aufgelöst wird: Standardmäßig überschreibt marginTop die Eigenschaft margin, unabhängig davon, welche zuerst übergeben wird. Die Kompilierung erfolgt im Babel-Plugin von StyleX, auf dem auch die offiziellen Bundler- und PostCSS-Integrationen aufbauen.

Derselbe Button in beiden Varianten

Die folgenden Buttons in Panda CSS und StyleX stellen dieselbe intent-Prop bereit. Der Unterschied liegt darin, wo die Styling-Entscheidungen getroffen werden.

// Panda: panda.config.ts defines theme.extend.tokens.colors.brand = { value: '#2563eb' }
import { cva } from '../styled-system/css'

const button = cva({
  base: { px: '4', py: '2', borderRadius: 'md', fontWeight: 'semibold' },
  variants: {
    intent: {
      primary: { bg: 'brand', color: 'white' },
      ghost: { bg: 'transparent', color: 'brand' },
    },
  },
  defaultVariants: { intent: 'primary' },
})

export function Button({ intent, ...props }) {
  return <button className={button({ intent })} {...props} />
}

// StyleX
import * as stylex from '@stylexjs/stylex'

const styles = stylex.create({
  base: { paddingInline: 16, paddingBlock: 8, borderRadius: 6, fontWeight: 600 },
  primary: { backgroundColor: '#2563eb', color: 'white' },
  ghost: { backgroundColor: 'transparent', color: '#2563eb' },
})

export function Button({ intent = 'primary', style, ...props }) {
  return <button {...props} {...stylex.props(styles.base, styles[intent], style)} />
}

In der Panda-Version besteht bg: 'brand' die Typprüfung nur, weil brand in der Konfiguration existiert und Codegen einen passenden Typ erzeugt hat. In der StyleX-Version ist jede Variante ein eigenes Objekt, und der style des Konsumenten wird zuletzt übergeben. Überall dort, wo er dieselbe Eigenschaft setzt wie die Basis oder die Variante, gewinnt der Wert des Konsumenten – ein Kampf um Spezifität findet nicht statt. Die Helper von Panda schränken ein, welche Werte Entwickler verwenden können. Die Merge-Regel von StyleX schränkt ein, wie die Styles einer Komponente die einer anderen überschreiben können.

Praktische Konsequenzen der Wahl zwischen Panda CSS und StyleX

Der unterschiedliche Ursprung zeigt sich im Alltag in drei Bereichen: wie der Build funktioniert, wie Theming funktioniert und was mit Werten geschieht, die erst zur Laufzeit existieren.

Workflow: Codegen vs. Compiler-Plugin

Bei Panda liegt ein generiertes Artefakt zwischen Ihrer Konfiguration und Ihren Komponenten, sodass die Änderung eines Tokens bedeutet, styled-system/ neu zu generieren. StyleX kommt ohne generiertes Verzeichnis aus. Das Babel-Plugin transformiert jedes Modul an Ort und Stelle, und die Konfiguration des Plugins steuert, wie Importe und Variablen aufgelöst werden.

Theming: Tokens vs. Variablen

Bei Panda ist das Theme die Token-Menge: Ändern Sie brand in der Konfiguration, ändert sich beim nächsten Build jede Verwendung. Bei StyleX ist Theming ein Override-Mechanismus, der auf die komponentenspezifischen Styles aufgesetzt wird. stylex.defineVars deklariert Variablen in einer .stylex.ts-Datei, und stylex.createTheme erzeugt Overrides, die Sie auf ein übergeordnetes Element anwenden:

// tokens.stylex.ts
import * as stylex from '@stylexjs/stylex'
export const colors = stylex.defineVars({ brand: '#2563eb' })

// app.tsx
import * as stylex from '@stylexjs/stylex'
import { colors } from './tokens.stylex'

const dark = stylex.createTheme(colors, { brand: '#60a5fa' })
<div {...stylex.props(dark)}>{children}</div>

Die Theming-APIs von StyleX funktionieren erst, wenn die Option unstable_moduleResolution des Babel-Plugins konfiguriert ist.

Dynamische Werte: Wo Zero-Runtime unhandlich wird

Ein Build-Time-Extractor sieht nur Werte, die im Quellcode stehen. Ein Wert, der erst zur Laufzeit bekannt ist – etwa eine vom Benutzer gewählte Farbe –, kann in keiner der beiden Bibliotheken zu einer atomaren Klasse werden. Der Leitfaden zu dynamischem Styling von Panda erklärt, dass der Extractor alles überspringt, was er nicht aus dem Quellcode lesen kann, und empfiehlt stattdessen Recipes, CSS-Variablen oder data-*-Attribute. StyleX geht mit dynamischen Styles anders um: Der Compiler erzeugt eine feste Klasse, die auf eine CSS-Variable verweist, und der Laufzeitwert wird am Element in diese Variable geschrieben.

Panda CSS vs. StyleX: Welches Problem haben Sie?

Treffen Sie die Wahl anhand Ihres Problems, nicht anhand der Feature-Liste. Ein kleines Team, dessen UI sich immer wieder von seinem Designsystem entfernt, hat genau das Problem, für das Panda gebaut wurde: Tokens werden zu Typen, und Werte außerhalb des Systems lassen sich nicht mehr kompilieren. Eine große Codebasis, in der die Styles einer Komponente immer wieder in andere durchsickern, hat genau das Problem, für das StyleX gebaut wurde: Jede Komponente besitzt ihre eigenen Styles, und die Merge-Reihenfolge an der Aufrufstelle bestimmt das Ergebnis.

Viele Projekte haben keines der beiden Probleme. Für sie erledigen CSS Modules oder ein Utility-Framework die Aufgabe mit weniger Build-Tooling, als jede der beiden Bibliotheken benötigt. Einen Vergleich zweier anderer Styling-Ansätze finden Sie unter Tailwind vs. Sass.

Bevor Sie sich für eine der beiden Bibliotheken entscheiden, identifizieren Sie den Styling-Bug, den Ihr Team immer wieder behebt. Handelt es sich um Design-Drift, prototypen Sie ein Recipe in Panda. Handelt es sich um Override-Konflikte, portieren Sie eine gemeinsam genutzte Komponente nach StyleX und beobachten Sie, wie sich ihre Konsumenten verhalten.

FAQs

Wie unterscheiden sich Hover-Zustände und Media Queries zwischen Panda CSS und StyleX?

In StyleX gehören Pseudoklassen und Media Queries als Objekt aus Bedingungen in den Wert einer Eigenschaft, und dieses Objekt benötigt einen default-Eintrag, den Sie auf null setzen können. Pseudoelemente wie ::placeholder bilden die Ausnahme: Sie werden als eigener Schlüssel auf oberster Ebene des Namespace geschrieben. Panda akzeptiert Bedingungen innerhalb einer Eigenschaft, etwa bg: { base: 'red.500', _hover: 'red.700' }, oder als Bedingungsobjekte, wobei integrierte Namen wie _hover und Mobile-First-Breakpoint-Schlüssel wie md und lg verwendet werden.

Kann StyleX Kindelemente so stylen, wie es die beliebigen Selektoren von Panda ermöglichen?

Nicht direkt. StyleX untersagt beliebige Selektoren und Styling auf Distanz, während css() in Panda beliebige Selektoren wie '& > *' akzeptiert. StyleX 0.16.0 hat die stylex.when-APIs eingeführt (ancestor, descendant, anySibling, siblingBefore und siblingAfter). Sie markieren ein Element mit stylex.defaultMarker(), und ein anderes Element ändert seine Styles, wenn das markierte Element gehovert oder fokussiert wird oder einem Attribut entspricht. Die Varianten descendant, anySibling und siblingAfter setzen den CSS-Selektor :has() voraus. Eine weitere dokumentierte Möglichkeit besteht darin, eine defineVars-Variable auf einem Elternelement zu setzen.

Wird stylex.props() im Browser ausgeführt?

Manchmal, und dann nur als kleiner Merge-Schritt. Der StyleX-Compiler wandelt stylex.create()-Aufrufe zur Build-Zeit in statisches atomares CSS um, und wenn Styles in derselben Datei erstellt und verwendet werden, kann er den stylex.props()-Aufruf vollständig entfernen. Überschreiten Styles Dateigrenzen, läuft stylex.props() als Funktion, die kompilierte Style-Objekte von links nach rechts zusammenführt und className- und style-Props für React zurückgibt. Sie erzeugt oder injiziert niemals CSS im Browser. Für Nicht-React-Frameworks wie Solid, Svelte, Qwik und Vue stellt StyleX zusätzlich stylex.attrs() bereit.

Was ist der Unterschied zwischen strictTokens und strictPropertyValues in Panda CSS?

strictTokens betrifft Eigenschaften, die auf Tokens basieren, wie color, bg und borderColor: Ist die Option aktiviert, werden dort nur Token-Werte akzeptiert. strictPropertyValues betrifft eine feste Liste von Eigenschaften mit bekannten Schlüsselwortwerten, wie display, position und overflow: Ist die Option aktiviert, wirft Panda einen Fehler, wenn ein Wert keinem dieser Schlüsselwörter entspricht. Beide Optionen aktivieren Sie in panda.config.ts. In beiden Fällen lässt sich ein roher Wert ohne TypeScript-Fehler verwenden, indem man ihn in eckige Klammern setzt, etwa [123px].