Tailwind CSS 4: Was neu ist und warum es ein Game Changer ist

Warum Tailwind 4 mehr ist als nur ein Update

Tailwind CSS 4 ist nicht "v3 mit neuen Features". Es ist ein kompletter Rewrite der Engine, mit einem radikal neuen Ansatz zur Konfiguration, nativer Nutzung moderner CSS-Features und massiv besserer Performance. Wer von v3 kommt, muss ein paar Dinge umlernen — aber die Investition lohnt sich innerhalb weniger Stunden.

Ich habe mittlerweile alle meine aktiven Projekte auf Tailwind 4 migriert, inklusive dieser Website. Die Erfahrung war durchgehend positiv: schnellere Builds, kleinere Bundles, klarere Konfiguration. Hier ist mein detaillierter Blick auf die wichtigsten Änderungen, was du bei der Migration beachten musst, und warum sich das Upgrade zu 99% lohnt.

Die fünf wichtigsten Änderungen

1. Neue Engine, geschrieben in Rust

Tailwinds Engine wurde in Rust neu geschrieben (Oxide Engine). Das Resultat: Build-Zeiten sind 5–10x schneller als in v3, inkrementelle Builds sind praktisch instant. Auf einem größeren Projekt, das vorher 800ms für einen Full Build brauchte, liegt v4 bei etwa 80–120ms. Der Unterschied ist beim Entwickeln spürbar — Hot Reload fühlt sich wie JIT-Magie an.

2. CSS-First-Konfiguration via @theme

Das ist die auffälligste Änderung. Kein tailwind.config.js mehr (zumindest nicht als Pflicht). Stattdessen wird alles in der CSS-Datei selbst über die @theme-Direktive definiert:

@import "tailwindcss";
 
@theme {
  --color-primary: oklch(65% 0.2 250);
  --color-accent: oklch(70% 0.18 320);
  --font-sans: "Inter", system-ui, sans-serif;
  --breakpoint-3xl: 120rem;
}

Der Vorteil: keine Sprach-Grenzen mehr zwischen Config und CSS. Designer können mit den Tokens arbeiten, ohne in JavaScript-Config-Dateien zu springen. Und die Tokens werden automatisch als native CSS-Variablen verfügbar — sie lassen sich von JavaScript, von Komponenten und von Drittcode nutzen.

3. Moderne CSS-Features unter der Haube

Tailwind 4 nutzt nativ:

• CSS Cascade Layers — saubere Layer-Struktur für Basis, Komponenten, Utilities
• Registered Custom Properties (@property) — typisierte CSS-Variablen mit Interpolation
• color-mix() — für Hover-Farben und dynamische Farbvariationen
• oklch() Farbraum als Default — wahrnehmungsgleichmäßige Farben
• Container Queries First-Class-Support (@container)
• @starting-style für Enter-Animationen ohne JavaScript

Das bedeutet: Du bekommst Features, die modernes CSS heute bietet, als Utility-Klassen, ohne selbst irgendwas konfigurieren zu müssen.

4. Automatic Content Detection

In v3 musstest du in der Config angeben, welche Dateien Tailwind scannen soll (content: ["./src/**/*.{ts,tsx}"]). In v4 passiert das automatisch — Tailwind findet deine Dateien selbst und erkennt, welche Klassen verwendet werden. Eine Konfiguration weniger, ein Konfigurationsfehler weniger.

5. Kleinere Bundles

Durch besseres Tree-Shaking, smartere Klassen-Generierung und den Einsatz von Cascade Layers sinken Bundle-Größen messbar. In meinen Projekten: zwischen 10% und 25% kleineres CSS. Das summiert sich bei größeren Applikationen auf mehrere hundert Kilobyte.

Was in der Migration bricht (und wie du es fixt)

Wenn du von v3 migrierst, sind die häufigsten Stolperfallen:

1. Import-Direktiven haben sich geändert

v3:

@tailwind base;
@tailwind components;
@tailwind utilities;

v4:

@import "tailwindcss";

2. Config-Datei wird zu @theme

Die gute Nachricht: Tailwind bietet einen automatischen Migrator (npx @tailwindcss/upgrade), der den Großteil der Arbeit erledigt. Bei komplexen Config-Files lohnt es sich, die Ausgabe danach einmal durchzugehen und Namen zu konsolidieren.

3. Manche Plugins brauchen Updates

Offizielle Plugins (@tailwindcss/typography, @tailwindcss/forms, @tailwindcss/container-queries) sind aktualisiert und funktionieren. Community-Plugins checken, ob sie eine v4-kompatible Version haben. Im Zweifel: ob du das Plugin überhaupt noch brauchst — viele v3-Plugins lösen Probleme, die in v4 nativ gelöst sind.

4. Dark-Mode-Variante

In v4 kannst du Dark Mode wahlweise via prefers-color-scheme oder über eine Klasse (class=dark) steuern — die Syntax ist in der @theme-Direktive leicht unterschiedlich zu v3. Einmal im Migrations-Leitfaden nachschauen, dann läuft es.

Migrations-Plan für bestehende Projekte

• Projekt < 50 Komponenten: 1–2 Stunden
• Projekt 50–200 Komponenten: 2–4 Stunden
• Großes Projekt mit vielen Plugins: 1–2 Tage

Schrittweise Migration ist möglich, aber bei den meisten Projekten lohnt es sich, an einem Nachmittag komplett zu migrieren. Die neue Engine ist so viel schneller, dass jede Stunde mit v3 danach irgendwie "alt" wirkt.

Die Features, die mich am meisten begeistern

1. @theme als zentraler Design-Token-Ort — endlich ein sauberer Ort für Farben, Schriftgrößen, Breakpoints
2. Container Queries als Utilities — @md:grid-cols-3 statt Medien-Queries
3. oklch()-Farben — für moderne Designs mit wahrnehmungsgleichmäßigen Farbverläufen
4. Automatic Content Detection — eine Konfigurations-Quelle weniger für Fehler
5. color-mix() Hover-States — hover:bg-primary/80 funktioniert mit beliebigen Farben

Wann sich das Upgrade nicht lohnt

Wenn du ein Projekt hast, das in Wartung ist und nicht weiterentwickelt wird, spart ein Upgrade nichts. Aber sobald du aktiv daran arbeitest, zahlt sich Tailwind 4 spätestens nach einer Woche aus.

Mein Fazit

Tailwind 4 ist das beste Update seit der Einführung der JIT-Engine. Die Kombination aus radikal schnelleren Builds, moderner CSS-First-Konfiguration, nativer Nutzung moderner CSS-Features und besseren Bundles macht es zu einem der wichtigsten Frontend-Tools 2026. Wenn du noch auf v3 bist: Upgrade. Die Migration dauert weniger als ein Arbeitstag und die Performance-Gewinne sind real.

Falls dein Projekt viele Custom-Utilities oder komplexe Plugin-Kombinationen hat und du unsicher bist, ob die Migration reibungslos läuft — ich habe mittlerweile ~15 Projekte migriert und kenne die üblichen Stolperfallen. Einmal gemeinsam durchgehen, 2–4 Stunden, und dein Projekt ist auf v4.