Tailwind CSS: perché lo uso in quasi tutti i miei progetti, e come lo imposto con la v4

Uso Tailwind CSS in quasi tutti i progetti nuovi, compreso questo sito. Non per moda: dopo anni di fogli di stile che crescevano a ogni pagina e di nomi di classe che nessuno osava toccare, è lo strumento che mi ha dato il miglior equilibrio tra velocità di sviluppo, coerenza del design e peso del CSS. Qui spiego perché, come lo imposto con la versione 4 e dove, con la stessa franchezza, non lo consiglio.

Il problema che risolve

Il CSS tradizionale basato su nomi semantici (.card-prodotto, .hero-titolo) ha un difetto strutturale: è globale e cresce per aggiunta. Ogni nuova pagina aggiunge regole ed eccezioni, le specificità si accumulano, e dopo qualche anno nessuno sa più cosa si può rimuovere senza rompere una pagina lontana. Il risultato è un file che solo cresce.

Tailwind sposta lo stile sull'elemento, con classi atomiche che usano un vocabolario finito: la scala di spaziature, la palette, le dimensioni dei caratteri del progetto. Ogni classe riguarda solo l'elemento su cui è scritta.

Perché lo uso

I token del design sono il vocabolario

Con la v4 i token si definiscono in CSS, dentro @theme: colori, famiglie, scale di spaziatura, raggi, ombre. Diventano variabili CSS native e, insieme, le uniche classi disponibili. Se il progetto parte da un file Figma con le sue variabili, queste diventano il tema una per una (lo spiego in Da Figma a WordPress). Un blu «quasi uguale» non può comparire per sbaglio.

Il CSS smette di crescere

Il CSS pubblicato contiene solo le classi usate nei template. Il vocabolario è finito, quindi una pagina nuova riusa classi esistenti invece di aggiungere regole. Il peso dello stile resta quasi costante: un vantaggio diretto su caricamento e rendering, di cui parlo in Core Web Vitals spiegati da uno sviluppatore.

Modifiche locali e sicure

Cambiare l'aspetto di un componente non ha effetti collaterali su altri. Per chi eredita il progetto, o per un'agenzia che mi affida una parte del lavoro, è la differenza tra intervenire con tranquillità e aver paura di toccare.

Responsive, stati e container query nello stesso posto

Varianti per larghezza, hover, focus-visible, disabled, preferenza di movimento ridotto e container query si scrivono accanto alla classe base. Gli stati di focus e di accessibilità diventano parte del componente, non un'aggiunta dimenticata.

Come lo imposto

Componenti, non classi ripetute

La critica più comune («l'HTML si riempie di classi») è giusta se si scrive tutto in pagina. In un progetto Nuxt o Vue ogni elemento ricorrente è un componente: la combinazione di classi di un pulsante vive in un solo file. Uso @apply con parsimonia, solo per piccole classi di base condivise.

Tema chiaro e scuro su variabili

In questo sito il tema chiaro non duplica le classi: rimappa le variabili di colore del tema. Il bianco diventa l'inchiostro, le gradazioni di grigio si invertono, e tutti i componenti che usano i token cambiano da soli. Le poche «isole» che devono restare scure (lo slider dei lavori, la finestra di codice, il gioco) dichiarano il tema scuro sul proprio contenitore. Un solo punto in cui controllare i contrasti, invece di centinaia di varianti dark:.

Contenuti lunghi

Il testo degli articoli arriva dal Markdown e non ha classi: si gestisce con un insieme di regole tipografiche dedicato, applicato al contenitore.

I limiti, senza girarci intorno

• Richiede di conoscere il CSS. Tailwind non lo sostituisce, lo rende più veloce da scrivere. Chi non conosce flexbox, grid e cascata non ci arriva con le classi.
• Senza disciplina sui componenti il markup diventa davvero illeggibile.
• Non si innesta bene su temi pronti e page builder, dove lo stile è già deciso altrove.
• Gli effetti molto particolari (animazioni complesse, shader, maschere) si scrivono comunque in CSS dedicato, ed è giusto così.

Quando non lo consiglio

Su un WordPress costruito con un tema pronto che funziona, o per un ritocco a un sito esistente in CSS tradizionale, introdurre Tailwind non ha senso: meglio rispettare ciò che c'è. Lo strumento si sceglie per il progetto, non il contrario.

Cosa cambia per chi commissiona il sito

Non serve sapere cos'è Tailwind per vederne gli effetti:

1. Pagine più leggere, perché il CSS pubblicato contiene solo ciò che si usa: un vantaggio misurabile soprattutto da telefono.
2. Coerenza visiva su tutto il sito, perché colori, spazi e caratteri vengono da un unico sistema di token.
3. Modifiche più rapide e meno rischiose: cambiare un dettaglio non rompe pagine lontane, e il costo degli interventi resta prevedibile nel tempo.
4. Codice leggibile da altri: Tailwind è uno standard diffuso, quindi un'agenzia o uno sviluppatore che arriva dopo trova convenzioni note, non un sistema inventato da me.
5. Tema chiaro e scuro, stati di focus, varianti responsive progettati insieme al componente, non aggiunti a fine progetto.

Per un'agenzia c'è un vantaggio in più: i token del proprio design system diventano il tema del sito, e il passaggio dal file di progetto al codice perde molto meno per strada.

Come la vedo io

Tailwind fa parte di un insieme di scelte coerenti: Nuxt e Vue per la struttura, componenti piccoli e riutilizzabili, token del design come unica fonte di colori e misure, generazione del sito in anticipo e pubblicazione con GitHub e Netlify. Ognuna riduce il numero di cose che possono andare storte. È lo stesso principio che mi ha portato a usare sempre meno temi pronti e page builder: meno strati tra il design e il codice, meno sorprese nel tempo.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Uso Tailwind con Nuxt e Vue per siti veloci, coerenti e facili da far evolvere, e traduco i progetti grafici in componenti fedeli al design su ogni schermo.

Se hai un progetto da impostare bene, scrivimi: in una chiacchierata di circa 20 minuti capiamo quale base tecnica gli serve. Il servizio è in Creazione siti web.