Tailwind CSS v4 è uscito con la promessa di essere "più veloce e più semplice". Un anno dopo l'abbiamo in produzione su tre progetti nati da poco e su una migrazione da v3 fatta con i denti. Ecco il bilancio senza entusiasmo da changelog.
Cosa cambia davvero
Il motore Oxide
Il rewrite in Rust del motore rende i build percettibilmente più rapidi. Su un design system di media grandezza siamo passati da qualche secondo a frazioni di secondo per il rebuild incrementale in dev. Non è un dettaglio: con il CSS ricalcolato ad ogni salvataggio, la differenza si sente nel flusso di lavoro quotidiano.
Configurazione CSS-first
Il salto concettuale grosso: il file tailwind.config.js non è più il centro del mondo. I token si dichiarano nel CSS con @theme, e le variabili CSS diventano cittadine di prima classe. Per chi ha un design system serio è una benedizione: colori, spacing e font vivono in un unico posto, leggibile anche da chi non conosce la sintassi JS della config.
Niente più contenuto da elencare
L'auto-detection dei file sorgente elimina la sezione content che tutti dimenticavano di aggiornare. Meno una fonte di bug silenziosi ("perché questa classe non viene generata?").
Dove ci siamo fatti male
- Plugin di terze parti in ritardo: alcuni plugin dell'ecosistema v3 hanno impiegato mesi ad adeguarsi. Su un progetto abbiamo dovuto riscrivere a mano un paio di utility custom che prima davamo per scontate.
- Browser target: v4 punta su feature CSS moderne (cascade layers,
color-mix(), proprietà registrate). Se devi supportare browser molto vecchi, verifica prima. Per noi non è stato un problema, ma va detto. - Migrazione della config: lo strumento di upgrade automatico fa l'80% del lavoro. Il restante 20%, soprattutto tema custom e valori arbitrari incrociati, è lavoro manuale che va testato visivamente pagina per pagina.
Progetto nuovo vs migrazione
La distinzione conta. Su un progetto nuovo, v4 è semplicemente meglio: parti CSS-first, non hai debito, il DX è ottimo. Su una migrazione da v3 il calcolo è diverso: se il progetto è stabile e non lo tocchi spesso, il ritorno è basso e il rischio di regressioni visive è reale. Migrarlo "perché è uscita la v4" non basta come motivo.
Il nostro approccio operativo
Progetti nuovi: v4 di default da subito. Progetti esistenti: migriamo solo quando c'è già un redesign in corso o un refactoring del design system pianificato, così la migrazione paga due volte. Migrare in isolamento, senza un obiettivo di prodotto, lo consideriamo tempo speso male.
Verdetto
Tailwind v4 è un upgrade genuino, non cosmetico: il motore è più veloce e la config CSS-first è come avremmo voluto Tailwind dall'inizio. Ma "genuino" non vuol dire "urgente". Adottalo senza esitare sul prossimo progetto; migra i vecchi quando hai un motivo di prodotto per rimetterci le mani, non prima.