Drei Utility-First-Frameworks, drei Blickwinkel: Quellcode-Qualität, Komponentenwelt und KI-gestützte Entwicklung. Am Ende steht ein klarer Gewinner.
Utility-First-CSS ist kein Trend mehr, sondern Standard. Fast jedes neue Projekt entscheidet sich irgendwo zwischen Tailwind, UnoCSS oder einer der Varianten dazwischen. Windi CSS gehört technisch dazu, nimmt aber eine Sonderrolle ein: Der Autor Anthony Fu hat es selbst zugunsten von UnoCSS aufgegeben. Das ist keine Kleinigkeit – es sagt viel über die Richtung.
Dieser Artikel beurteilt alle drei aus drei konkreten Blickwinkeln, die 2026 relevant sind: Wie sieht der Quellcode aus? Wie verhält sich das Framework in einer Komponentenwelt? Und was bedeutet KI-gestützte Entwicklung für die Wahl?
Kurz zu den Ausgangspositionen
Tailwind CSS ist das Standardframework. Es hat das größte Ökosystem, die beste Dokumentation, das meiste Tooling. Mit v4 wurde die Build-Pipeline auf einen nativen Rust-Prozessor umgestellt — deutlich schneller als v3, kein PostCSS mehr notwendig. Der JIT-Modus ist jetzt Default und kein experimentelles Feature mehr.
Windi CSS war der erste überzeugende On-Demand-Ansatz: Klassen werden nicht aus einem vollständigen CSS-Pool herausgepurgt, sondern direkt beim Parsen der Dateien erzeugt. Das Ergebnis: kürzere Build-Zeiten, kein Purge-Schritt. Windi CSS hat Tailwind zeitweise klar überholt – aber die Entwicklung ist eingeschlafen. Das letzte Release liegt weit zurück, Issues bleiben offen, der Maintainer hat sich verabschiedet.
UnoCSS ist das Nachfolgekonzept von Anthony Fu, direkt aus der Erfahrung mit Windi CSS entstanden. Es ist keine Framework-Implementierung, sondern eine Engine: keine Klassen sind vordefiniert, alles kommt über Presets. preset-wind emuliert Tailwind/Windi-Klassen, preset-icons integriert Iconsets als Utility-Klassen, preset-attributify erlaubt Klassen als HTML-Attribute statt als String. Das macht UnoCSS strukturell anders als die anderen beiden.
Blickwinkel 1: Quellcode-Qualität
In allen drei Frameworks landet man bei ähnlichem HTML: Klassen-Strings in Komponenten. Der Unterschied liegt im, was darunter passiert.
Bei Tailwind bedeutet jeder neue Breakpoint, jede Zustandsvariante und jede Anpassung eine Erweiterung der tailwind.config-Datei. Die Konfiguration ist JavaScript, aber mit untypisierter Struktur und eigener Auflösungslogik. Custom Values landen in []-Syntax direkt im Template – text-[1.125rem] ist valides Tailwind, macht Quellcode aber schwerer lesbar.
Windi CSS hat dasselbe Muster. Wer Windi statt Tailwind wählt, bekommt schnellere Builds, aber keine bessere Quellcode-Qualität. Das ist kein Vorwurf — das war nie das Ziel.
UnoCSS verschiebt die Ebene. Die Konfiguration ist TypeScript-first, typsicher und composable:
// uno.config.ts
import { defineConfig, presetWind, presetIcons } from 'unocss'
export default defineConfig({
presets: [presetWind(), presetIcons()],
rules: [
['grid-auto-flow-dense', { 'grid-auto-flow': 'dense' }],
[/^grid-cols-fit-(\d+)$/, ([, n]) => ({
'grid-template-columns': `repeat(auto-fit, minmax(${n}px, 1fr))`
})],
],
shortcuts: {
'btn': 'inline-flex items-center gap-2 px-4 py-2 rounded-lg font-medium transition-colors',
'btn-primary': 'btn bg-blue-600 text-white hover:bg-blue-700',
}
})Eigene Regeln sind reguläre TypeScript-Funktionen. Shortcuts bündeln häufige Muster. Das ist kein Konfigurationsformat mit versteckten Konventionen — das ist normaler Code, testbar, composable, versionierbar.
Ein weiterer Unterschied: Weil UnoCSS nur das erzeugt, was wirklich verwendet wird, ist das Output-CSS konsistent klein. Bei Tailwind entscheidet das Purge-Setup darüber, was im Bundle landet. Falsch konfiguriert — und es landet zu viel.
Gewinner Quellcode: UnoCSS.
Blickwinkel 2: Komponentenwelt (Astro, Vue, React, Svelte)
Komponenten-basiertes Arbeiten verändert die Anforderungen an ein CSS-Framework erheblich. Der kritische Punkt: In einer Komponentenwelt ist es nicht sinnvoll, CSS global zu konfigurieren und dann nach verwendeten Klassen zu suchen. Das Klassen-Scanning ist ein Workaround für ein Konzept, das eigentlich nicht nach Komponenten gedacht wurde.
Tailwind hat diesen Workaround verfeinert, aber nicht beseitigt. Die content-Konfiguration definiert, welche Dateien gescannt werden. Bei großen Projekten oder Monorepos mit Shared-Components wird das fehleranfällig — Klassen in Packages werden ohne explizite Konfiguration nicht erfasst.
Windi CSS war hier besser: das Scanning passiert zur Laufzeit, nicht zur Build-Zeit. Aber „besser” ist relativ, weil das Grundproblem bleibt: Klassen sind Strings in Vorlagen, das Framework sucht sie.
UnoCSS mit preset-attributify kehrt die Logik um:
<!-- Statt class-String -->
<button class="inline-flex items-center px-4 py-2 bg-blue-600 text-white rounded-lg hover:bg-blue-700">
<!-- Mit attributify -->
<button
inline-flex
items-center
px="4"
py="2"
bg="blue-600"
text="white"
rounded="lg"
hover:bg="blue-700"
>Das ist optional, aber es zeigt, dass UnoCSS das Komponenten-Denken in die CSS-Engine bringt, nicht umgekehrt. Für Astro ist das besonders interessant, weil die Template-Syntax bereits attribute-orientiert ist.
Für Vite-basierte Projekte (also fast alles außer Webpack-Legacy) ist UnoCSS als Vite-Plugin integriert — kein separater PostCSS-Schritt, keine Build-Kette, die es kennen muss. Bei Tailwind v4 gilt das ebenfalls, aber die Integration ist noch im Aufbau.
In React macht der Unterschied sich weniger bemerkbar — JSX-Klassen-Strings sind ohnehin Standard. Hier ist Tailwind durch die schiere Ökosystem-Größe im Vorteil: shadcn/ui, Radix Themes, Headless UI — alles Tailwind.
Das ist der ehrlichste Einwand gegen UnoCSS in der Komponentenwelt: Wer auf Drittkomponenten-Libraries aufbaut, die Tailwind-Klassen eingebettet haben, kann nicht einfach wechseln.
Gewinner Komponentenwelt: UnoCSS (für eigene Komponentensysteme), Tailwind (für Library-getriebene React-Projekte).
Blickwinkel 3: KI-gestützte Entwicklung
Dieser Blickwinkel wird unterschätzt. Wie ein Framework mit KI-Assistenz zusammenarbeitet, entscheidet zunehmend über produktive Nutzung.
Tailwind hat den größten Trainingsdatensatz. Jedes Sprachmodell hat tausende von Tailwind-Projekten gesehen. Der Effekt ist konkret: Wenn ein LLM Komponenten generiert, werden es Tailwind-Klassen sein. hover:bg-blue-700, flex items-center gap-4, rounded-xl shadow-md — das kommt korrekt und konsistent, weil es aus Millionen von Zeilen Trainingsdaten gelernt wurde.
Das ist ein echter Vorteil. Nicht weil Tailwind besser ist, sondern weil KI-Output direkt verwendbar ist, ohne manuelles Übersetzen.
Windi CSS verliert hier. Die Community ist zu klein, die Syntax zu nah an Tailwind, aber nicht identisch genug, dass Ausgaben zuverlässig passen.
UnoCSS ist interessanter als es auf den ersten Blick aussieht. Mit preset-wind sind alle Tailwind-Klassen gültig — der KI-Output funktioniert. Gleichzeitig erlaubt die Engine etwas, das Tailwind nicht kann: eigene semantische Regeln, die KI-Modelle über das System Prompt oder Konventionen erlernen können.
Ein konkretes Beispiel: Ein UnoCSS-Projekt mit eigenen Shortcuts wie card, section-hero, tag-primary kann einem LLM diese Konventionen mitgeben. Das Modell generiert dann semantisch kohärente Ausgaben — statt rounded-xl bg-white shadow-md border border-gray-200 p-6 einfach card. Das ist ein anderes Qualitätsniveau.
Darüber hinaus ist UnoCSS mit Tools wie Cursor oder VS-Code-Extensions besser konfigurierbar: Custom rules erscheinen in der Autovervollständigung, Shortcuts werden erkannt. Tailwind hat hier ebenfalls gute Tools — die Tailwind IntelliSense-Extension ist exzellent — aber UnoCSS-Projekte können eigene Intellisense-Definitionen mitbringen.
Gewinner KI-Entwicklung: Tailwind (kurzfristig, durch Trainingsdaten), UnoCSS (mittelfristig, durch semantische Anpassbarkeit).
Der Gewinner
UnoCSS.
Nicht weil Tailwind schlecht ist — Tailwind v4 ist sehr gut. Sondern weil UnoCSS das Richtige löst: Es trennt Framework von Konvention. Die Engine bleibt stabil, die Regeln gehören zum Projekt. Das ist langfristig robuster als ein einzelnes Framework, das Konventionen vorschreibt.
Windi CSS ist ausgeschieden. Nicht wegen der Idee, sondern wegen der Realität: Keine aktive Entwicklung, keine Perspektive. Wer Windi CSS heute noch nutzt, sollte migrieren — zu UnoCSS, mit preset-wind, ist die Migration meist ein Nachmittag.
Die einzige Situation, in der Tailwind die klarere Wahl bleibt: große React-Projekte, die auf Tailwind-basierte Component-Libraries (shadcn, Radix etc.) aufbauen. Da ist der Wechsel zu UnoCSS mehr Aufwand als Nutzen.
Für alle anderen — Astro, Vue, Svelte, neue Projekte, eigene Design-Systeme, Teams, die eigene Konventionen pflegen — ist UnoCSS die modernere, flexiblere und technisch überlegene Wahl.
Wer direkt einsteigen will: Die UnoCSS-Dokumentation erklärt die Architektur gut, und das Interactive Docs zeigt in Echtzeit, welche Klassen welches CSS erzeugen.