Tailwind CSS: Grenzen von Design-Systemen für Entwickler

Warum Tailwind CSS skalierbare Design Systems einschränkt: Ansatz-Analyse

Tailwind CSS beschleunigt das Prototyping, doch der Utility-First-Ansatz sorgt bei der Skalierung für Kopfschmerzen. In Design Systems brauchen Komponenten wie Buttons Kombinationen aus Varianten, Größen und Zuständen. Eine neue Variante wie btn-focus muss nahtlos mit btn-sm, btn-lg oder btn-outline harmonieren. Zustände wie Hover (15 % dunkler) oder Active (10 % heller) sollten einheitlich überall greifen. Traditionelle Frameworks lösen das mit Mixins, z. B.:

.button-variant-other(@color; @background; @border);

Tailwind fehlen eingebaute Tools für solche nahtlose Integrationen ohne Abstriche.

CVA: Schnell, aber begrenzt

Shadcn nutzt CVA für Buttons mit festen Varianten und Größen:

variant "default" | "outline" | "ghost" | "destructive" | "secondary" | "link"
size "default" | "xs" | "sm" | "lg" | "icon" | "icon-xs" | "icon-sm" | "icon-lg"

Vorteile:

• Rasante Entwicklung ohne Datei-Hopping.
• Saubere API für einfache Fälle.

Nachteile zeigen sich in Langzeitprojekten:

• primary outlined small ohne Hacks unmöglich.
• Feste Kombos häufen Tech-Schulden nach 6+ Monaten an.

Gut für Simple-Apps, aber im Enterprise-Entwickeln treibt es Kosten hoch.

CSS-Variablen: Die flexible Lösung

CSS-Variablen trennen Zustandslogik von Varianten:

.btn {
  @apply inline-flex items-center justify-center rounded px-4 py-2 font-body;
  background-color: var(--btn-color);
  color: var(--btn-text, white);
}

.btn:hover {
  background-color: color-mix(in srgb, var(--btn-color), black 15%);
}

.btn:active {
  filter: brightness(1.1);
}

.btn-primary {
  --btn-color: theme('colors.blue.600');
}
.btn-whatever {
  --btn-color: …;
}

Schlüsselvorteile:

• Auto-Zustände für jede Farbe.
• Einfache Varianten-Erweiterung per Variablen.
• Funktioniert mit jeder UI-Bibliothek.

Nachteil für Tailwind-Fans: Etwas weniger Speed, da Styles in separate Dateien wandern.

@utility Directive: Ein Utility-Hack

Die Direktive erzeugt Klassen dynamisch:

@utility btn-* {
  font-size: --value(--text-ui-*, [length]);
  background-color: --value(--color-ui-*, [color]);
  color: --value(--color-ui-*-text, [color]);
}

Das passt zu Tailwind-Modifiern für Hover oder Responsive. Aber:

• btn-focus skaliert nicht auf sm oder lg – funktionale Klassen hapern.
• primary small outline erfordert fragile Komponenten-Anpassungen.
• Bricht bei komplexen Kombos zusammen.

Ansatz-Vergleich

| Ansatz | Speed | Skalierbarkeit | Zustandsintegration | Tailwind-Abhängigkeit |

|-------------|---------|----------------|---------------------|-----------------------|

| CVA | Hoch | Niedrig | Begrenzt | Voll |

| CSS-Variablen | Mittel | Hoch | Voll | Niedrig |

| @utility | Mittel | Mittel | Teilweise | Hoch |

CVA glänzt bei MVPs, CSS-Variablen in der Produktion, @utility als Mittelweg.

Wichtige Erkenntnisse

• Tailwind diktiert keine Struktur: Utility-First erfordert DIY-Systeme.
• Komponenten als Klassen: Sperrt komplexe Design Systems in starre Optionen ein.
• Tech-Schulden-Alarm: Frühe Einfachheit bedeutet Refactoring in sechs Monaten.
• Alternativen liefern: CSS-Variablen bieten Flexibilität ohne Tailwind-Abschied.

Tailwind rockt für schnelle Starts, aber reife Design Systems brauchen Hybride oder gelockerte Utility-Zügel.

— Editorial Team