Tailwind CSS mi ha cambiato la vita: storia di una conversione

Diciamocelo: quando ho visto per la prima volta Tailwind CSS, ho pensato "ma chi è il pazzo che vuole scrivere class="flex items-center justify-between p-4 bg-blue-500" invece di una classe semantica?". Era il 2019, avevo già 20 anni di esperienza con CSS, e questa roba mi sembrava una follia.

Eppure oggi, nel 2025, uso Tailwind in praticamente tutti i miei progetti. Dai siti web professionali agli e-commerce, dalle landing page alle web app su misura. E non perché sia di moda, ma perché mi ha letteralmente cambiato il modo di lavorare.

Il mio percorso con i CSS (ovvero: quante volte ho cambiato idea)

Quando ho iniziato a fare siti web nel 2000, scrivevo CSS inline. Poi sono passato ai file CSS esterni con classi tipo .header-main, .button-primary, .card-product. Sembrava professionale. Poi è arrivato Bootstrap, e per anni ho pensato "ok, questo è il modo giusto". Componenti pronti, grid system, responsive out of the box.

Il problema? Ogni progetto finiva per sembrare simile agli altri. E quando dovevo personalizzare, mi ritrovavo a sovrascrivere stili Bootstrap con CSS custom. Un casino. File CSS che crescevano a dismisura, specificità che diventava un incubo, e quella sensazione costante di "ma dov'è definito questo stile?".

Un mio cliente, un ristoratore di Riva del Garda, mi ha chiamato un giorno disperato: "Alex, il sito è lento. Puoi guardare?" Ho aperto gli strumenti per sviluppatori e ho visto: 187 KB di CSS. Di cui probabilmente usavamo il 20%. Bootstrap intero, più tutti i miei override, più roba che nemmeno ricordavo di aver scritto.

La svolta (o meglio: quando ho smesso di essere testardo)

Ho provato Tailwind per la prima volta su una landing page semplice. Progetto piccolo, cliente paziente, quindi potevo sperimentare. All'inizio è stata dura: dover cercare le classi nella documentazione, ricordarsi i nomi, scrivere HTML che sembrava verboso.

Ma dopo due giorni è successa una cosa strana. Ho dovuto modificare il design di un componente. Di solito apro il CSS, cerco la classe giusta, modifico, ricarico, verifico che non abbia rotto nient'altro. Con Tailwind? Ho cambiato le classi nell'HTML. Fatto. Zero ansia da "ho rotto qualcosa in un'altra pagina".

Il file CSS finale della landing page? 8 KB. Otto. Contro i 187 di prima. E non perché fosse un progetto più semplice, ma perché Tailwind include solo le classi che usi davvero.

Cosa è cambiato davvero nel mio workflow

La velocità di sviluppo è schizzata. Quando realizzo un e-commerce a Trento o un gestionale, non devo più passare dal browser all'editor CSS e tornare indietro. Tutto succede nell'HTML (o nel componente Vue/React se lavoro con framework JavaScript).

E poi c'è la consistenza. Con Tailwind hai una scala di spacing predefinita: p-2, p-4, p-8. Non più "metto 17px di padding perché mi sembra giusto". Questo significa che tutti i miei progetti hanno un ritmo visivo coerente, anche se li realizzo a distanza di mesi.

I dubbi (che avevo e che ancora sento dai clienti)

"Ma Alex, non è roba che cambia ogni anno? E se fra tre anni Tailwind non esiste più?"

Capisco il dubbio. L'ho avuto anche io. Ma la verità è che i concetti dietro Tailwind (utility-first, atomic CSS) sono solidi. E anche se domani Tailwind sparisse, il codice rimane leggibile. Vedi flex justify-between items-center e capisci cosa fa, anche senza documentazione.

Un cliente mi ha chiesto: "E se devo modificare il sito fra qualche anno e tu non ci sei?" Risposta onesta: con Tailwind è più facile per un altro sviluppatore capire il codice. Tutto è lì, nell'HTML. Non deve aprire 5 file CSS per capire perché un bottone è rosso.

Quando NON uso Tailwind (perché non sono un fanatico)

Ci sono progetti dove non ha senso. Se devo fare un restyling veloce su un sito WordPress esistente che usa un tema custom, non ristruturo tutto per inserire Tailwind. Sarebbe overkill.

E se il cliente ha già un framework CSS in uso (tipo un'azienda con un design system consolidato), non forzo il cambiamento. Le tecnologie devono servire il progetto, non il contrario.

Come ho imparato davvero (oltre la documentazione)

La documentazione ufficiale di Tailwind è ottima, ma la vera svolta è stata quando ho iniziato a usare Tailwind UI per vedere componenti reali. Non per copiarli pari pari, ma per capire come composizioni complesse si traducono in classi utility.

E poi c'è la pratica. Ho rifatto tre progetti vecchi in Tailwind, per puro esercizio. Landing page che avevo realizzato con Bootstrap, le ho riscritte. Il terzo progetto mi è costato metà tempo del primo.

Oggi qui a Trento, quando un cliente mi chiede un sito web o una web app, so già che userò Tailwind (a meno di motivi specifici per non farlo). Non perché sia trendy, ma perché mi fa lavorare meglio. E lavorare meglio significa consegnare prima, con codice più pulito, e meno mal di testa quando devo fare modifiche.

Ho oltre vent'anni di esperienza nel web, e credetemi: quando trovi uno strumento che davvero migliora il tuo lavoro quotidiano, te ne accorgi. Tailwind per me è stato questo. Una di quelle scoperte che ti fa pensare "cavolo, come ho fatto prima senza?"

Se stai valutando Tailwind, il mio consiglio è: prova su un progetto piccolo. Una landing page, un prototipo. Non leggere solo tutorial, metti le mani sul codice. Io ci ho messo un paio di settimane per abituarmi, ma ne è valsa la pena.

E se hai dubbi o vuoi farmi domande sulla mia esperienza con Tailwind (o su qualsiasi aspetto dello sviluppo web e software), scrivimi pure. Sono sempre felice di scambiare opinioni con altri sviluppatori o con clienti curiosi.