Ich werde etwas sagen, das einigen Federn raufen könnte: Ich habe Ende 2025 aufgehört, Tailwind CSS in neuen Projekten zu verwenden, und habe nie zurückgeschaut. Nicht, weil Tailwind schlecht ist -- es ist wirklich hervorragend bei dem, was es tut. Aber weil Vanilla CSS so gut geworden ist, dass die Kompromisse für die Art von Projekten, die wir bauen, keinen Sinn mehr ergeben.

Design Tokens stehen im Kern dieser Verschiebung. Die Idee, deine Design-Entscheidungen als wiederverwendbare, plattformunabhängige Variablen zu speichern, ist nicht neu. Aber die Tools und Browser-Unterstützung für CSS Custom Properties in 2026 haben sich so weit entwickelt, dass du ein vollständiges Design-Token-System mit null Build-Schritten, null Abhängigkeiten und null Utility-Klassen-Auswendiglernen bauen kannst. Lass mich dir zeigen, wie.

Inhaltsverzeichnis

Vanilla CSS Design Tokens Without Tailwind in 2026

Was Design Tokens wirklich sind

Design Tokens sind die atomaren Werte, die deine visuelle Sprache definieren. Farben, Abstände, Typografie, Schatten, Grenzradien, Animationsdauern -- alles, das eine Design-Entscheidung repräsentiert. Der Begriff wurde 2014 vom Design-Team von Salesforce geprägt, aber das Konzept hat sich seitdem erheblich weiterentwickelt.

Hier ist die Schlüsselerkenntnis, die die meisten Menschen übersehen: Design Tokens sind nicht nur Variablen. Sie sind ein Vertrag zwischen Design und Engineering. Wenn dein Designer sagt "verwende die primäre Action-Farbe", wird das auf einen Token abgebildet, nicht auf einen Hex-Wert. Wenn sie sagen "mittlerer Abstand", auch das ist ein Token.

Die W3C Design Tokens Community Group hat das Design Tokens Format Module Specification veröffentlicht, und während es sich noch weiterentwickelt, haben sich die Kernideen gefestigt. Tokens existieren in Schichten:

  1. Primitive Tokens (Rohwerte wie #1a73e8 oder 16px)
  2. Semantic Tokens (Zweck-gesteuerte Aliases wie color-action-primary)
  3. Component Tokens (auf spezifische UI-Elemente beschränkt, wie button-background)

Diese dreischichtige Architektur ist das, was große Systeme handhabbar macht. CSS Custom Properties passen perfekt dazu.

Warum mich Vanilla CSS überzeugt hat

Sei mir ehrlich erlaubt, von meinem Weg zu erzählen. Ich habe Tailwind jahrelang glücklich verwendet. Produktionsseiten damit gebaut. Es Clients empfohlen. Aber mehrere Dinge haben sich geändert:

CSS hat aufgeholt. Nesting, :has(), Container Queries, @layer, @scope, color-mix(), oklch(), Relative Color Syntax -- das sind keine experimentellen Features mehr. Sie sind Baseline in jedem großen Browser in 2026. Die Lücke, die Utility Frameworks gefüllt haben? Sie ist dramatisch geschrumpft.

Bundle-Größe ist wichtiger als je zuvor. Mit Core Web Vitals, die direkt Suchranking beeinflussen, zählt jedes Kilobyte. Ein gut strukturiertes Vanilla CSS Token-System wiegt fast nichts. Tailwinds JIT-Compiler ist clever, aber er gibt immer noch CSS für jeden Utility aus, den du verwendest.

Wartungskosten sind real. Ich habe Tailwind-Projekte geerbt, bei denen Components 30+ Utility-Klassen hintereinander haben. Das Lesen von className="flex items-center justify-between px-4 py-2 bg-white dark:bg-gray-800 rounded-lg shadow-sm hover:shadow-md transition-shadow duration-200 border border-gray-200 dark:border-gray-700" macht keinen Spaß. Mit Design Tokens und einer dünnen CSS-Schicht ist die Absicht klarer.

Design-Engineering Handoff verbessert. Wenn Tokens in CSS mit Tokens in Figma 1:1 übereinstimmen, werden Gespräche präzise. Keine "welche Tailwind-Klasse entspricht dieser Figma-Variable?" mehr.

Das ist kein heiliger Krieg. Wenn Tailwind für dein Team funktioniert, nutze es weiter. Aber wenn du etwas Neues startest und maximale Kontrolle mit minimaler Abstraktion möchtest, sind Vanilla CSS Tokens eine ernsthafte Überlegung wert.

Deine Token-Architektur einrichten

Lasst uns das von Grund auf bauen. Ich werde die Dateistruktur verwenden, die wir bei mehreren Headless-CMS-Projekten bei Social Animal verfeinert haben, passt sie aber an deine Bedürfnisse an.

Das Kernprinzip: Tokens fließen nach unten durch Spezifitätsschichten.

tokens/
├── primitives.css       /* Rohwerte */
├── semantic.css         /* Zweck-gesteuerte Aliases */
├── components/
│   ├── button.css
│   ├── card.css
│   └── input.css
├── themes/
│   ├── light.css
│   └── dark.css
└── index.css            /* Import-Orchestrierung */

Dein index.css nutzt @layer, um eine klare Kaskade herzustellen:

@layer primitives, semantic, themes, components;

@import './primitives.css' layer(primitives);
@import './semantic.css' layer(semantic);
@import './themes/light.css' layer(themes);
@import './components/button.css' layer(components);
@import './components/card.css' layer(components);
@import './components/input.css' layer(components);

Das ist wichtig. @layer gibt dir explizite Kontrolle über die Kaskade ohne Kampf um Spezifität. Primitives werden durch Semantic Tokens überschrieben, die durch Themes überschrieben werden, die durch Components überschrieben werden. Saubere Hierarchie.

Vanilla CSS Design Tokens Without Tailwind in 2026 - architecture

Primitive Tokens: Deine Rohwerte

Primitives sind deine Palette. Sie sind nicht gedacht, direkt in Components verwendet zu werden -- denk von ihnen als die Farbe auf deinem Regal, bevor du entscheidest, was du anmalen willst.

/* primitives.css */
:root {
  /* Farben mit OKLCH für perceptually uniform Paletten */
  --color-blue-50: oklch(0.97 0.01 250);
  --color-blue-100: oklch(0.93 0.03 250);
  --color-blue-200: oklch(0.87 0.06 250);
  --color-blue-300: oklch(0.78 0.10 250);
  --color-blue-400: oklch(0.68 0.15 250);
  --color-blue-500: oklch(0.58 0.19 250);
  --color-blue-600: oklch(0.50 0.19 250);
  --color-blue-700: oklch(0.42 0.17 250);
  --color-blue-800: oklch(0.35 0.14 250);
  --color-blue-900: oklch(0.27 0.10 250);

  /* Spacing-Skala (modular, auf 4px-Gitter basierend) */
  --space-1: 0.25rem;   /* 4px */
  --space-2: 0.5rem;    /* 8px */
  --space-3: 0.75rem;   /* 12px */
  --space-4: 1rem;      /* 16px */
  --space-5: 1.25rem;   /* 20px */
  --space-6: 1.5rem;    /* 24px */
  --space-8: 2rem;      /* 32px */
  --space-10: 2.5rem;   /* 40px */
  --space-12: 3rem;     /* 48px */
  --space-16: 4rem;     /* 64px */
  --space-20: 5rem;     /* 80px */
  --space-24: 6rem;     /* 96px */

  /* Typografie-Skala */
  --font-size-xs: 0.75rem;
  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-md: 1.125rem;
  --font-size-lg: 1.25rem;
  --font-size-xl: 1.5rem;
  --font-size-2xl: 1.875rem;
  --font-size-3xl: 2.25rem;
  --font-size-4xl: 3rem;

  /* Font-Gewichte */
  --font-weight-normal: 400;
  --font-weight-medium: 500;
  --font-weight-semibold: 600;
  --font-weight-bold: 700;

  /* Grenzradius */
  --radius-sm: 0.25rem;
  --radius-md: 0.5rem;
  --radius-lg: 0.75rem;
  --radius-xl: 1rem;
  --radius-full: 9999px;

  /* Schatten */
  --shadow-sm: 0 1px 2px oklch(0 0 0 / 0.05);
  --shadow-md: 0 4px 6px oklch(0 0 0 / 0.07);
  --shadow-lg: 0 10px 15px oklch(0 0 0 / 0.1);
  --shadow-xl: 0 20px 25px oklch(0 0 0 / 0.1);

  /* Dauern */
  --duration-fast: 100ms;
  --duration-normal: 200ms;
  --duration-slow: 300ms;
  --duration-slower: 500ms;
}

Ich nutze hier OKLCH, weil es ein wirklich besserer Farbraum ist. Anders als HSL ist die Helligkeit in OKLCH perceptually uniform -- eine Helligkeit von 0.5 sieht tatsächlich wie mittleres Grau aus, unabhängig vom Farbton. Deine Farbskalen sehen konsistent über das gesamte Spektrum aus. Alle großen Browser unterstützen es jetzt.

Semantic Tokens: Wo die Magie passiert

Semantic Tokens referenzieren Primitives und geben ihnen Bedeutung. Das ist die Schicht, die Theming möglich macht und dein CSS selbsterklärt.

/* semantic.css */
:root {
  /* Oberflächenfarben */
  --color-surface-primary: var(--color-white, #fff);
  --color-surface-secondary: var(--color-gray-50);
  --color-surface-tertiary: var(--color-gray-100);
  --color-surface-inverse: var(--color-gray-900);

  /* Text-Farben */
  --color-text-primary: var(--color-gray-900);
  --color-text-secondary: var(--color-gray-600);
  --color-text-tertiary: var(--color-gray-400);
  --color-text-inverse: var(--color-white, #fff);
  --color-text-link: var(--color-blue-600);
  --color-text-link-hover: var(--color-blue-700);

  /* Action-Farben */
  --color-action-primary: var(--color-blue-600);
  --color-action-primary-hover: var(--color-blue-700);
  --color-action-primary-active: var(--color-blue-800);

  /* Feedback-Farben */
  --color-feedback-success: var(--color-green-600);
  --color-feedback-warning: var(--color-amber-500);
  --color-feedback-error: var(--color-red-600);
  --color-feedback-info: var(--color-blue-500);

  /* Grenz-Farben */
  --color-border-primary: var(--color-gray-200);
  --color-border-secondary: var(--color-gray-100);
  --color-border-focus: var(--color-blue-500);

  /* Semantic Spacing */
  --space-inline-xs: var(--space-1);
  --space-inline-sm: var(--space-2);
  --space-inline-md: var(--space-4);
  --space-inline-lg: var(--space-6);
  --space-stack-xs: var(--space-1);
  --space-stack-sm: var(--space-2);
  --space-stack-md: var(--space-4);
  --space-stack-lg: var(--space-8);
  --space-stack-xl: var(--space-12);
}

Beachte, dass hier kein Wert hart codiert ist. Alles referenziert Primitives. Wenn du morgen rebrand möchtest, änderst du Primitives. Wenn du anpassen möchtest, wie "primary action" sich anfühlt, änderst du Semantic Tokens. Der Component Code muss nie wissen.

Component Tokens: Die letzte Schicht

Component Tokens schränken Design-Entscheidungen auf spezifische UI-Elemente ein. Das ist optional für kleine Projekte, aber essentiell für alles mit einem Design-System.

/* components/button.css */
.button {
  --_bg: var(--color-action-primary);
  --_bg-hover: var(--color-action-primary-hover);
  --_bg-active: var(--color-action-primary-active);
  --_text: var(--color-text-inverse);
  --_radius: var(--radius-md);
  --_padding-block: var(--space-2);
  --_padding-inline: var(--space-4);
  --_font-size: var(--font-size-sm);
  --_font-weight: var(--font-weight-semibold);
  --_shadow: var(--shadow-sm);
  --_transition: var(--duration-normal);

  display: inline-flex;
  align-items: center;
  gap: var(--space-2);
  padding: var(--_padding-block) var(--_padding-inline);
  background: var(--_bg);
  color: var(--_text);
  font-size: var(--_font-size);
  font-weight: var(--_font-weight);
  border-radius: var(--_radius);
  box-shadow: var(--_shadow);
  transition: background var(--_transition), box-shadow var(--_transition);
  border: none;
  cursor: pointer;

  &:hover {
    background: var(--_bg-hover);
    box-shadow: var(--shadow-md);
  }

  &:active {
    background: var(--_bg-active);
  }

  &.--secondary {
    --_bg: transparent;
    --_text: var(--color-action-primary);
    --_shadow: none;
    border: 1px solid var(--color-border-primary);

    &:hover {
      --_bg: var(--color-surface-secondary);
    }
  }

  &.--ghost {
    --_bg: transparent;
    --_text: var(--color-text-primary);
    --_shadow: none;

    &:hover {
      --_bg: var(--color-surface-secondary);
    }
  }
}

Die --_ Präfix-Konvention (mit Unterstrich) signalisiert "privat" Component-Tokens. Sie wird vom Browser nicht erzwungen, ist aber ein klares Signal für andere Entwickler: diese Tokens sind intern für diese Component.

Auch -- schau, wie CSS Nesting hier funktioniert. Kein Präprozessor nötig. Das ist natives CSS in 2026.

Dark Mode und Theming ohne Framework

Hier zahlt sich die Token-Architektur wirklich aus. Dark Mode wird zu einer Frage der Neuzuweisung von Semantic Tokens.

/* themes/dark.css */
@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-primary: var(--color-gray-900);
    --color-surface-secondary: var(--color-gray-800);
    --color-surface-tertiary: var(--color-gray-700);
    --color-surface-inverse: var(--color-white, #fff);

    --color-text-primary: var(--color-gray-50);
    --color-text-secondary: var(--color-gray-300);
    --color-text-tertiary: var(--color-gray-500);
    --color-text-inverse: var(--color-gray-900);
    --color-text-link: var(--color-blue-400);
    --color-text-link-hover: var(--color-blue-300);

    --color-border-primary: var(--color-gray-700);
    --color-border-secondary: var(--color-gray-800);

    --shadow-sm: 0 1px 2px oklch(0 0 0 / 0.2);
    --shadow-md: 0 4px 6px oklch(0 0 0 / 0.3);
    --shadow-lg: 0 10px 15px oklch(0 0 0 / 0.4);
  }
}

/* Manuelle Toggle-Unterstützung */
[data-theme="dark"] {
  --color-surface-primary: var(--color-gray-900);
  /* ... dieselben Overrides ... */
}

Deine Components ändern sich überhaupt nicht. Zero Dark Mode Classes. Zero bedingter Logik. Die Tokens handhaben alles.

Möchtest du ein Brand-Theme für einen White-Label-Client? Dasselbe Muster:

[data-theme="client-acme"] {
  --color-blue-500: oklch(0.55 0.20 280); /* Ihr Lila statt Blau */
  --color-action-primary: var(--color-blue-500);
  --radius-md: 1rem; /* Sie mögen rundere Ecken */
}

Wir verwenden diesen Ansatz umfangreich in unseren Next.js Development-Projekten, bei denen Multi-Tenant-Theming eine häufige Anforderung ist.

Responsive Tokens mit Container Queries

Das ist etwas, das du mit Tailwind wirklich nicht elegant machen kannst (zumindest nicht jetzt). Container Queries lassen dich Token-Werte auf Basis der Container-Größe ändern, nicht nur des Viewports.

.card-grid {
  container-type: inline-size;
  container-name: card-grid;
}

@container card-grid (max-width: 500px) {
  .card {
    --_padding: var(--space-3);
    --_title-size: var(--font-size-base);
    --_gap: var(--space-2);
  }
}

@container card-grid (min-width: 501px) {
  .card {
    --_padding: var(--space-6);
    --_title-size: var(--font-size-lg);
    --_gap: var(--space-4);
  }
}

Components, die auf ihren eigenen Kontext reagieren, statt auf den Viewport. Das ist besonders leistungsstark beim Bauen von Component-Bibliotheken für Astro-Seiten, wo Components über wildly unterschiedliche Layouts wiederverwendet werden.

Design Tokens mit Figma synchronisieren

Figma Variables (2023 gelauncht, seitdem erheblich erweitert) stimmen direkt mit unserem dreischichtigen Token-Modell überein. Hier ist der Workflow:

  1. Tokens in Figma definieren mit ihrem Variables Panel (primitives → semantic → component)
  2. Tokens exportieren mit dem Tokens Studio Plugin oder Figmas REST API
  3. In CSS transformieren mit Style Dictionary oder den neueren Cobalt UI Tools
  4. In dein Repo committen als dein tokens/ Verzeichnis

Eine Style Dictionary Config für CSS Output sieht so aus:

{
  "source": ["tokens/**/*.json"],
  "platforms": {
    "css": {
      "transformGroup": "css",
      "buildPath": "src/styles/tokens/",
      "files": [
        {
          "destination": "primitives.css",
          "format": "css/variables",
          "filter": { "filePath": "tokens/primitives" }
        },
        {
          "destination": "semantic.css",
          "format": "css/variables",
          "filter": { "filePath": "tokens/semantic" }
        }
      ]
    }
  }
}

Das Ergebnis ist eine CI-Pipeline, bei der Design-Änderungen in Figma automatisch in deine CSS Tokens fließen. Keine manuelle Übersetzung, keine Drift.

Performance-Vergleich: Vanilla CSS vs Tailwind

Ich habe Benchmarks auf einer echten Marketing-Site durchgeführt, die wir umgebaut haben -- gleiches Design, zwei Implementierungen. Hier sind die Zahlen:

Metrik Tailwind v4 Vanilla CSS Tokens Unterschied
Gesamt CSS-Größe (gzipped) 14.2 KB 6.8 KB -52%
First Contentful Paint 1.2s 1.0s -17%
Largest Contentful Paint 2.1s 1.8s -14%
CSS Parse-Zeit 3.2ms 1.4ms -56%
HTML-Größe (gzipped) 28.4 KB 22.1 KB -22%
Build-Zeit 1.8s 0.4s* -78%

*Vanilla CSS mit nur @import Bundling via Lightning CSS.

Der Unterschied in der HTML-Größe ist bemerkenswert -- Tailwinds Utility Classes addieren signifikantes Gewicht zu deinem Markup. Auf einer Seite mit 200+ Elementen summieren sich diese Class Strings.

Das gesagt, Tailwind v4 (Anfang 2025 gelauncht) machte großer Verbesserungen mit seiner Oxide Engine. Die Lücke ist enger geworden. Aber Vanilla CSS mit null Build-Abhängigkeiten ist schwer zu schlagen auf roher Performance.

Echte Token-Dateistruktur

Hier ist die tatsächliche Struktur aus einem aktuellen Projekt -- ein Headless-Commerce-Site gebaut mit Next.js und Sanity:

src/styles/
├── tokens/
│   ├── primitives/
│   │   ├── colors.css
│   │   ├── spacing.css
│   │   ├── typography.css
│   │   ├── shadows.css
│   │   ├── borders.css
│   │   └── motion.css
│   ├── semantic/
│   │   ├── colors.css
│   │   ├── spacing.css
│   │   └── typography.css
│   ├── themes/
│   │   ├── light.css
│   │   ├── dark.css
│   │   └── high-contrast.css
│   └── index.css
├── components/
│   ├── button.css
│   ├── card.css
│   ├── input.css
│   ├── modal.css
│   ├── navigation.css
│   └── typography.css
├── layouts/
│   ├── grid.css
│   └── container.css
├── utilities/
│   └── helpers.css          /* Ein paar Utility Classes, die wir wirklich brauchen */
├── reset.css
└── main.css

Die utilities/helpers.css Datei ist interessant -- ich schreibe immer noch eine Handvoll Utility Classes für wirklich wiederverwendbare Muster:

/* utilities/helpers.css */
.visually-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

.flow > * + * {
  margin-block-start: var(--flow-space, var(--space-stack-md));
}

.cluster {
  display: flex;
  flex-wrap: wrap;
  gap: var(--cluster-gap, var(--space-inline-md));
  align-items: center;
}

Beachte, wie sogar die Utilities Tokens referenzieren. Alles bleibt verbunden.

Tools, die das praktisch machen

Du brauchst nicht viel, aber ein paar Tools machen die DX signifikant besser:

Tool Zweck Anmerkungen
Lightning CSS Bundling, Minifizierung, Vendor Prefixing Ersetzt PostCSS für die meisten Use Cases. Unglaublich schnell.
Style Dictionary 4 Token-Format-Transformation Figma → CSS, iOS, Android aus einer single Source
Cobalt UI W3C DTCG Token Tools Neuere Alternative zu Style Dictionary, Spec-aligned
Tokens Studio Figma Plugin für Token-Verwaltung Best-in-class Figma Integration
CSS Utility Kit (VS Code) Autocomplete für Custom Properties Zeigt Token-Werte on Hover
Open Props Pre-made CSS Custom Property Library Großer Startpunkt, wenn du nicht von Grund auf bauen möchtest

Lightning CSS verdient einen speziellen Callout. Geschrieben in Rust, es handhabet @import Inlining, Nesting-Kompilation für ältere Browser, und Minifizierung in einem Pass. Das nutzen wir in den meisten unserer Headless-CMS-Builds jetzt.

lightningcss --bundle --minify src/styles/main.css -o dist/styles.css

Das war's. Keine PostCSS Config. Keine Plugin Chain. Ein Command.

Häufig gestellte Fragen

Kann ich Design Tokens ohne Build-Schritt nutzen?

Absolut. Wenn du moderne Browser ansprichst (und 2026 solltest du), funktionieren native CSS Custom Properties ohne Kompilation. Das Einzige, das du verlierst, ist @import Bundling in eine einzelne Datei -- Browser handhaben mehrere CSS-Datei-Importe gut, obwohl du für Production Performance bundeln möchtest. Lightning CSS oder sogar ein einfaches cat Command kann das handhaben.

Wie vergleichen sich Vanilla CSS Design Tokens mit Tailwind v4?

Tailwind v4 ist tatsächlich zu CSS Custom Properties intern übergegangen, was den Ansatz validiert. Der Unterschied liegt in Developer Experience: Tailwind gibt dir Utility Classes zum Anwenden in HTML, Vanilla Tokens geben dir Design-Variablen zum Nutzen in deinem eigenen CSS. Vanilla Tokens erzeugen kleineres CSS und HTML Output, bieten mehr Flexibilität für Theming, und erfordern nicht, ein Class-Naming-System zu lernen. Tailwind bietet schnellere Prototyping und stärkere Konsistenz-Erzwingung für größere Teams.

Was ist mit TypeScript Type Safety für Design Tokens?

Wenn du CSS Modules oder CSS-in-JS nutzt, kannst du TypeScript Types von deinen Token-Dateien generieren. Style Dictionary 4 und Cobalt UI beide unterstützen TypeScript Output. Für reines CSS geben dir VS Code Extensions wie CSS Variable Autocomplete Editor-Level Safety mit Autocomplete und Validierung.

Sollte ich Open Props statt meine eigenen Tokens zu bauen nutzen?

Open Props ist ein ausgezeichneter Startpunkt, besonders für Prototypen oder kleinere Projekte. Es stellt einen gut-gestalteten Satz von CSS Custom Properties out of the box bereit. Für Production Design Systems aber wirst du wahrscheinlich deine eigenen Primitives definieren möchten, die deine Brand matchten. Du kannst Open Props als Referenz nutzen und sein Ansatz zu Dingen wie Easing Functions oder Shadow Scales cherry-picken.

Wie handhabe ich Design Tokens in einem Monorepo mit mehreren Apps?

Erstelle ein gemeinsames tokens Package, das deine CSS Dateien exportiert. Jede App importiert das Token Package und kann ihre eigenen Theme Overrides addieren. Das funktioniert wunderschön mit Workspaces in pnpm oder npm. Wir haben das für Multi-Brand E-Commerce Clients gemacht, wo jede Storefront die gleichen Primitive Tokens teilt, aber unique Semantic Mappings hat.

Ist Vanilla CSS langsamer zu entwickeln als Tailwind?

Initial, ja -- du richtest Infrastruktur ein, die Tailwind dir kostenlos gibt. Aber nach der ersten Woche oder zwei ist Velocity vergleichbar oder schneller. Du schaust nicht zwischen HTML und einer Utility Class Referenz hin und her. Du schreibst CSS, das wie Englisch liest. Und wenn du etwas ändern möchtest, änderst du es an einer Stelle, statt nach jedem Instance von bg-blue-500 zu suchen.

Wie überzeuge ich mein Team, Tailwind fallen zu lassen?

Framiere das nicht als Tailwind fallen lassen -- framiere es als Design Tokens Adoption. Fang an, einen Token Layer neben Tailwind einzuführen: definiere deine Custom Properties, referenziere sie in einem tailwind.config Theme. Mit der Zeit findest du vielleicht, dass das Token System die meiste Arbeit macht und Tailwind optional wird. Lass das Team organisch zu dieser Schlussfolgerung kommen.

Was ist mit Component Libraries wie Shadcn/UI, die sich auf Tailwind verlassen?

Shadcn/UI ist fantastisch, aber seine Tailwind Abhängigkeit ist Implementierungsdetail, nicht fundamentale Architektur. Die Component Patterns und Accessibility Logic sind das, das Wichtige. Mehrere Community Forks sind entstanden, die Vanilla CSS Tokens statt Tailwind Classes nutzen. Du kannst auch gradually Shadcn Components migrieren, um dein Token System zu nutzen -- die darunter liegenden Radix UI Primitives kümmern sich nicht, wie du sie stylest.

Kann ich diesen Ansatz mit Astro oder Next.js nutzen?

Absolut. Beide Frameworks handhaben Vanilla CSS nativ ohne Konfiguration. Astros Scoped Styles funktionieren perfekt mit CSS Custom Properties, da Tokens in :root definiert natürlich in Scoped Component Styles kaskadieren. Next.js unterstützt CSS Modules neben Global Token Dateien. Wir nutzen genau dieses Setup in unseren Next.js-Projekten und Astro-Builds regelmäßig. Wenn du das für ein neues Projekt erkundest, kontaktiere uns -- wir sind glücklich zu teilen, was wir gelernt haben.