Perché gli Sviluppatori Stanno Migrando da Tailwind CSS a Structured Vanilla CSS

Da Utility-First a Struttura Semantica

Otto anni dopo aver abbracciato con entusiasmo Tailwind CSS, la sviluppatrice Julia Evans sta tracciando una nuova rotta. In un recente post sul blog, descrive una migrazione di una settimana di diversi siti lontano dal framework utility-first verso HTML semantico e CSS vanilla. Il suo viaggio riflette una più ampia maturazione tra gli sviluppatori che, avendo imparato da tali framework, ora cercano maggiore controllo ed espressività.

Evans attribuisce a Tailwind il merito di aver fornito una struttura cruciale in un momento in cui le sue abilità CSS erano meno sviluppate. Offriva sistemi per stili di reset, palette di colori e scale di caratteri, prevenendo il caos. Tuttavia, ora trova i suoi vincoli limitanti e la sua dipendenza dai sistemi di build ingombranti per i suoi progetti.

La migrazione è stata guidata da diversi fattori. Tailwind è evoluto richiedendo un sistema di build, che Evans preferiva evitare, portando a file CSS statici grandi. Si è anche trovata a mischiare Tailwind con CSS vanilla, creando mal di testa per la manutenzione. In ultima analisi, il desiderio di più HTML semantico e la libertà di utilizzare funzionalità CSS native moderne ha spinto il cambiamento.

Costruire un'Architettura CSS Strutturata

L'approccio di Evans implica la costruzione di un'architettura CSS deliberata e multilivello. Ha iniziato copiando il reset Preflight di Tailwind, riconoscendo la sua dipendenza da convenzioni come `box-sizing: border-box` universale. Ciò forma una base stabile sulla quale stratifica i propri sistemi.

Il cuore della sua architettura è un modello basato su componenti, ispirato da framework JavaScript ma implementato puramente in CSS. Ogni componente visivo ottiene una classe univoca e il proprio file CSS. L'obiettivo è l'isolamento: la modifica degli stili di un componente non dovrebbe rompere un altro. Ciò è imposto per convenzione, utilizzando selettori nidificati all'interno della classe di ogni componente.

"L'idea è che ogni 'componente' abbia una classe univoca," scrive Evans. "Il CSS per un componente non sovrascrive mai il CSS per qualsiasi altro componente." Questa modularità rende significativamente più facile ragionare sugli stili, confinando le modifiche a file specifici e gestibili.

Implementazione di Sistemi di Design e Utilità

Oltre ai componenti, Evans stabilisce sistemi condivisi per la coerenza. Mantiene un file `colors.css` centralizzato con proprietà personalizzate CSS (variabili) per la sua palette, assicurando che tutti i colori siano definiti in un unico posto. Per la tipografia, adotta la scala dei caratteri di Tailwind ma la implementa con variabili CSS.

Ciò sostituisce le classi di shorthand del framework come `text-lg` con dichiarazioni più esplicite, ma ancora sistematiche, come `font-size: var(--size-lg);`. Mantiene anche un piccolo insieme di classi di utilità per problemi trasversali, come `.sr-only` per lettori di schermo, ma mantiene questa sezione minima e stabile.

Per gli stili di base che si applicano a livello di sito, Evans è cauta. Inizia con quasi nulla—attualmente solo una regola di layout di sezione e un colore di link—e pianifica di spostare gli stili dai componenti nel livello di base solo quando emergono schemi chiari. Questo approccio dal basso verso l'alto previene un'eccessiva progettazione prematura.

Ripensare i Layout e il Design Responsivo

Un cambiamento significativo è nella gestione dello spazio e del design responsivo. Abbandonando le utility di padding/margin di Tailwind, Evans mira a uno spaziatura principiale controllata da componenti di layout esterni. Utilizza selettori come il "selettore gufo" (`* + *`) per gestire lo spazio tra i figli in modo sistematico.

Forse il cambiamento più profondo è il suo approccio ai layout responsivi. Invece delle media query guidate dai breakpoint di Tailwind (`md:text-xl`), sta esplorando la potenza di CSS Grid. Funzionalità come `repeat(auto-fit, minmax(...))` consentono layout fluidi basati su colonne che si adattano senza breakpoint espliciti.

Evidenzia anche `grid-template-areas` come uno strumento di layout dichiarativo potente non disponibile all'interno del paradigma di utilità di Tailwind. Questa esplorazione nelle capacità native CSS rappresenta un vantaggio chiave nell'allontanarsi da un framework: la capacità di sfruttare la piena potenza in evoluzione della piattaforma web.

Semplificare la Catena di Strumenti e Guardare Avanti

Il processo di build è notevolmente semplificato. Funzionalità CSS moderne come `@import` nativo e selettori nidificati consentono a Evans di sviluppare senza alcun passaggio di build. Per la produzione, utilizza opzionalmente `esbuild`, un bundler veloce e semplice che apprezza per essere un binario statico e basato su standard web.

La riflessione di Evans sottolinea che questa migrazione non è un rifiuto del valore di Tailwind ma un'evoluzione. Il framework ha servito come un ottimo insegnante, impartendo principi di sistema di design. Ora, re-implementa selettivamente quei principi guadagnando la flessibilità di utilizzare funzionalità CSS emergenti come `@layer`, `@scope`, query dei contenitori e subgrid.

La sua esperienza rispecchia un sentimento in crescita: man mano che le abilità CSS degli sviluppatori si approfondiscono e il linguaggio stesso diventa più potente, i compromessi di un framework di utilità rigoroso cambiano. Il desiderio di markup semantico, complessità ridotta della catena di strumenti e creatività illimitata sta portando molti a riabbracciare CSS vanilla con una nuova prospettiva più strutturata.