Fino a qualche anno fa i CSS erano un linguaggio progettato per essere semplice da usare e da gestire. L’esempio più convincente di questa loro caratteristica era sicuramente CSS Zengarden, che da una comune struttura HTML mostrava come fosse possibile creare layout di notevole impatto visivo. Il culmine si ebbe nel biennio 2006 – 2008 e coincise con l’avvento dei social network. Di colpo i CSS furono costretti a dover gestire layout non complessi da un punto di vista grafico (Facebook è sostanzialmente semplice a livello di impaginazione) ma sicuramente impegnativi per il numero di strutture HTML da formattare. Da lì gli sviluppatori sentirono la necessità di condensare alcuni pattern e best practices in strumenti per il riutilizzo del codice e la semplificazione del workflow. Nacquero così i framework CSS.
Il problema dei framework CSS oggi è costituito dall’abuso che molti sviluppatori ne fanno. Questi framework sono infatti progettati per gestire progetti di grandi dimensioni, e il loro design concept è appunto quello.
Usare questi framework per piccoli o medi progetti è come uccidere una mosca con un bazooka. I pattern usati in questi framework hanno una reale utilità solo quando (come si è detto) le strutture HTML sono molto numerose e complesse.
Molti sviluppatori usano questi framework anche su template e temi per CMS. Un difetto di questi framework è quello di ridurre l’impaginazione degli elementi a degli insiemi di griglie basati su calcoli matematici precisi. Il problema è che se invece di avere un contenitore a 960 pixel siamo costretti ad usarne uno a 750 o a 787, l’intero sistema di calcoli va rivisto.
Questi framework, a livello di creatività , tendono inoltre a ridurre ad un minimo comun denominatore tutti i layout. Il rischio è quello di avere una serie infinita di siti praticamente identici, salvo alcune differenze grafiche, come i colori, i font o le immagini.
Il succo è questo: i framework CSS vanno usati quando ce n’è un reale ed effettivo bisogno, e non per dimostrare che si è al passo coi tempi. Il rischio è quello di delegare ad un codice scritto da altri le nostre decisioni in fatto di layout.
E non possiamo correre questo rischio.