Tailwind v4: Die Neuerungen, die alles verändern

Tailwind v4 ist keine Aktualisierung, es ist eine Veränderung der Natur. Die v3 war ein JavaScript-Tool, das CSS schrieb. Die v4 ist CSS, das die Fähigkeiten des Browsers nutzt. Das sieht man schon in der ersten Datei.

Diese Website läuft auf Tailwind 4.3. Hier ist, was sich wirklich in unserer täglichen Arbeit geändert hat.

Die Konfigurationsdatei ist verschwunden

In v3 lebten Ihre Palette, Ihre Schriftarten und Ihre Breakpoints in tailwind.config.js — einer JavaScript-Datei, die von einem Stylesheet aus unsichtbar war und die man erneut lesen musste, um zu verstehen, woher eine Farbe kam.

In v4 existiert diese Datei nicht mehr. Unsere wurde durch einen @theme-Block im CSS ersetzt:

@import 'tailwindcss';

@theme {
  --color-ink: #0e0e0c;
  --color-bone: #f2ebdb;
  --color-acid: #ccff33;
  --color-rust: #e94e1b;

  --font-display: 'Fraunces', 'Times New Roman', serif;
  --font-sans: 'Geist', system-ui, sans-serif;
}

Drei unmittelbare Konsequenzen:

1. Eine einzige Importzeile ersetzt die drei alten Direktiven @tailwind base, @tailwind components und @tailwind utilities.
2. Jeder Wert wird zu einer nativen CSS-Variable. --color-acid ist in einer Tailwind-Klasse (bg-acid) und in handgeschriebenem CSS (var(--color-acid)) verwendbar. In v3 sprachen diese beiden Welten nicht miteinander, ohne ein Plugin.
3. Ihre Token sind zur Laufzeit lesbar. Eine Komponente kann eine Farbe aus dem Theme direkt aus JavaScript lesen, was unmöglich war, wenn sie in einer Konfigurationsdatei kompiliert wurde.

Wir nutzen das, um abgeleitete Farben direkt im Theme zu mischen:

--color-ink-soft: color-mix(in srgb, var(--color-ink) 68%, var(--color-bone));

Diese Zeile hätte in v3 keinen Sinn gemacht.

PostCSS ist nicht mehr in der Mitte

Unser Projekt enthält weder tailwind.config.js noch postcss.config.js. Das offizielle Vite-Plugin (@tailwindcss/vite) reicht aus. Die neue Engine ist in Rust geschrieben, und der Build unserer 219 Seiten, Stylesheets eingeschlossen, dauert etwas über sechs Sekunden.

Weniger Konfigurationsdateien bedeuten weniger Orte, an denen sich ein Verhalten verstecken kann. Bei einem Projekt, das zwei Jahre später wieder aufgegriffen wird, ist das das Teuerste.

Der Preis: der Browser

Das ist der Punkt, den die Ankündigungen unter den Tisch kehren. Tailwind v4 stützt sich auf moderne CSS-Funktionen: @property, color-mix(), Cascade Layers (@layer). Konkret bedeutet das mindestens Safari 16.4, Chrome 111 und Firefox 128.

Wenn Ihr Publikum Unternehmensrechner mit alten Versionen umfasst — ein häufiger Fall in Industrie und Verwaltung —, überprüfen Sie Ihre Statistiken, bevor Sie migrieren. Es gibt kein automatisches Fallback: In einem zu alten Browser wird das Layout nicht degradiert, es bricht.

Für eine öffentliche Website 2026 ist die Frage geklärt. Für ein Intranet verdient sie fünf Minuten Analyse.

Was sich konkret in der Arbeit ändert

• Beliebige Werte treten in den Hintergrund. Wenn ein Token eine CSS-Variable ist, wird bg-[#ccff33] überflüssig: Man schreibt bg-acid, und die Farbe bleibt an einer Stelle änderbar.
• Die Grenze zwischen Tailwind und handgeschriebenem CSS verschwimmt. Unsere Astro-Komponenten mischen Utility-Klassen und scoped <style>-Blöcke, die die gleichen Variablen nutzen. Keine Palette-Duplikation mehr.
• Die Migration von v3 ist real. Das Tool npx @tailwindcss/upgrade macht den Groschen der Arbeit, aber Third-Party-Plugins und aufwändige Konfigurationen erfordern manuelle Überarbeitung. Rechnen Sie mit einem halben Tag bei einem Projekt mittlerer Grösse, nicht zehn Minuten.

Sollte man migrieren?

Neues Projekt: ja, ohne Diskussion.

Bestehendes Projekt in v3, das funktioniert: keine Eile. Die v3 funktioniert weiterhin. Der richtige Zeitpunkt ist eine visuelle Überarbeitung, wenn Sie ohnehin die Palette anpassen wollten.

Projekt mit vielen Third-Party-Plugins: überprüfen Sie zuerst deren v4-Kompatibilität. Dort verstecken sich die bösen Überraschungen, nicht im Kern des Tools.