Tailwind CSS 4 : ce qui change vraiment

📚 Introduction

Tailwind 3 était déjà rapide. Tailwind 4 redéfinit ce qu’on appelle “rapide”. L’équipe a entièrement réécrit le moteur en Rust, repensé le pipeline d’intégration aux bundlers modernes (Vite en tête), et déplacé la configuration depuis JavaScript vers… du CSS.

Sur mon site, l’upgrade Tailwind 3 → 4 s’est faite presque sans douleur. Mais derrière l’apparente continuité, beaucoup de choses bougent en coulisses. Voici ce qu’il faut retenir.

⚡ Un nouveau moteur, vraiment

Le compilateur Oxide, écrit en Rust, est l’argument le plus tangible de la version 4. Sur un projet de taille moyenne :

les builds initiaux sont environ 3 à 5 fois plus rapides ;
les builds incrémentaux en mode dev tombent sous la barre des 50 ms ;
la détection des classes est plus permissive (notamment dans les fichiers Astro, MDX et templates Blade) sans devoir lister manuellement chaque chemin.

Sur les projets multi-paquets en mono-repo, c’est même plus impressionnant : le nouveau moteur évite de re-scanner les fichiers inchangés, ce qui change radicalement l’expérience en local.

🧩 La configuration migre dans le CSS

C’est le changement le plus visible côté code. Plus besoin de tailwind.config.js pour la majorité des projets : les tokens et les overrides se déclarent directement dans le CSS via @theme :

@import 'tailwindcss';
 
@theme {
	--font-display: 'Noto Sans Variable', sans-serif;
	--color-brand: oklch(72% 0.18 156);
	--breakpoint-3xl: 1920px;
}

L’avantage est double : la configuration est visible dans les DevTools, et toutes les valeurs sont des CSS variables natives, donc accessibles partout en runtime, modifiables à la volée et compatibles avec les thèmes dynamiques.

🔌 Intégration Vite officielle

Tailwind 4 expose un plugin Vite natif. Plus besoin de PostCSS pour la majorité des projets :

// vite.config.js
import { defineConfig } from 'vite';
import tailwindcss from '@tailwindcss/vite';
 
export default defineConfig({
	plugins: [tailwindcss()]
});

Pour Astro, c’est encore plus simple :

import tailwindcss from '@tailwindcss/vite';
 
export default defineConfig({
	vite: { plugins: [tailwindcss()] }
});

C’est un soulagement pour qui galérait avec les versions de postcss, autoprefixer et les plugins concurrents qui se marchaient dessus.

🆕 Quelques nouveautés concrètes

@variant pour définir ses propres variantes en CSS, sans plugin JS.
Container queries intégrées (@container) sans plugin externe.
Color spaces modernes : OKLCH supporté nativement dans les tokens.
text-shadow-* disponible nativement (sans plugin tiers).
field-sizing-* pour les textarea qui s’auto-redimensionnent.

C’est l’accumulation de ces petites améliorations qui rend l’écosystème plus agréable au quotidien, surtout pour ceux qui aiment écrire le moins de CSS personnalisé possible.

⚠️ Quelques points de friction

Les plugins Tailwind 3 ne sont pas tous compatibles. Vérifiez avant de migrer si vous dépendez de @tailwindcss/typography ou de plugins communautaires.
La documentation a évolué : si vous cherchez “comment configurer X”, assurez-vous de lire la doc Tailwind 4, pas les vieux posts de blog qui décrivent encore l’ancien fichier de config JS.
Les snippets générés par certains LLM peuvent encore citer la syntaxe v3. Un quick check des classes générées s’impose.

🎉 Conclusion

Tailwind 4, c’est moins de configuration JavaScript, plus de CSS standard, et un build qui suit enfin la cadence des outils modernes (Vite, Bun, esbuild). L’ergonomie au quotidien y gagne franchement.

Pour un projet existant en v3, comptez quelques heures de migration et un test sérieux des plugins utilisés. Pour un projet greenfield, il n’y a plus aucune raison de commencer en v3.

🎨 Tailwind CSS 4 : ce qui change vraiment au quotidien