Sebbene il titolo di questo post sia una domanda, all’interno non troverete una risposta, o perlomeno la risposta di ogni buon esperto è ‘dipende’.

Questa introduzione serve a chiarire subito che non farò un confronto tra le due metodologie (basta cercare sul web per trovarne a zilioni), voglio invece riassumere quanto ho imparato nella mia esperienza personale.

Il nome della classe

Queste due metodologie vengono spesso associate a semplici naming convention, il termine usato per applicare le singole classi è invece la rappresentazione finale di un approccio strutturale molto radicale e che non può essere in alcun modo sottovalutato, il primo passo da fare consiste quindi nel capire le basi su cui nascono.

CSS Semantico

È indubbiamente il più antico dei due e possiamo farlo risalire al ‘lontano’ 2003 con la pubblicazione del sito CSS Zen Garden. L’idea alla base era che fosse possibile cambiare l’aspetto di un sito cambiando solo il file CSS e senza modificare l’HTML, applicando una separazione completa tra stile e markup.
Le classi CSS, essendo il codice HTML immutabile, non potevano avere riferimenti allo stile dell’elemento ma potevano rappresentarne solo l’identità, da cui nomi come: .header, .title, .card, .block, .media, ecc…; oggi queste classi vengono anche definite come Component Classes.
Esse avevano uno scopo reale dal momento il cui gli ID o la ‘cascata’ non erano sufficienti per riconoscere l’elemento a cui applicare lo stile.
Il primo problema sorto in relazione a questo sistema è quello della specificità: usando contemporaneamente id, classi e selettori complessi il codice diventa molto poco leggibile, l’applicazione degli stili molto instabile e l’utilizzo di !important diventava la soluzione finale.
La nuova parola d’ordine era: tenere bassa la specificità! Il che significava: non usare gli ID, non usare !important e usare il meno possibile i selettori a cascata.
La conseguenza è che ad ogni (o quasi) nodo di pagina, per avere lo stile corretto, va assegnata una classe che richiedeva lunghissimi scervellamenti per essere identificata correttamente.
Un sussidio agli sviluppatori arriva dalla naming convention BEM, che tramite la suddivisione degli elementi in Blocco, Elemento e Modificatore consente di creare delle architetture css molto più solide e gestibili.
Una ulteriore problematica arriva dalla duplicazione del codice: molti componenti di pagina, pur avendo una valenza differente, condividevano alcune caratteristiche di stile che di conseguenza veniva replicate in numero indefinito, rendendo complessa la manutenzione del codice nel tempo.
Per sopperire a queste problematiche è possibile usare alcune funzionalità dei pre/post-processori CSS (Sass, Less, Postcss, ecc...) insieme ad alcuni concetti espressi dalla metodologia Object Oriented CSS, per dare al codice una struttura che sia semplice da gestire sia nel breve che nel lungo termine.
Tutto il concetto però si basa su un presupposto tecnico non sempre valido: quante volte è effettivamente non praticabile la modifica del codice HTML?

CSS Funzionale

L’esigenza cambia completamente quando nascono i primi framework CSS (Bootstrap o Foundation, solo per citarne un paio).
In questi sistemi preconfezionati sono presenti delle classi semantiche (in Bootstrap abbiamo .cards, .navbar, .btn, ecc…) molto ben definite con alcune personalizzazioni possibili tramite alcune classi come: .pull-left, .text-center, .hidden e altre, tutt’altro che semantiche.
Queste classi funzionali vengono anche definite Utility Classes, proprio per differenziarle da quelle sematiche, introducendo quindi un principio di gestione ibrida.
I framework facilitano molto lo sviluppo dei nuovi siti, anche chi non ha competenze avanzate di CSS è in grado di impostare un layout inserendo nel codice le classi come da manuale, con la conseguenza che gli utilizzatori sono costretti ad usare tutti lo stesso codice HTML, portando al diffondersi di layout tutti uguali; era però nata una nuova necessità.

Utility First CSS

I progettisti di interfaccie, o UI/UX Designer, avevano l’esigenza di uno strumento che consentisse loro di sviluppare rapidamente nuovi layout e prototipi senza la necessità di conoscere approfonditamente il linguaggio CSS, ma anche senza le limitazioni e la standardizzazione che i framework CSS del tempo imponevano.
Una decina di anni dopo CSS Zen Garden appaiono nell’ambiente i primi framework composti unicamente di Utility Classes, a partire da Atomic CSS e Tachyons (si definisce un functional css framework) fino ad arrivare a Tailwind CSS (che usa espressamente il termine utility-first css framework).
Quest’ultimo ha avuto grosso successo perchè è diventato il framework prescelto dagli sviluppatori Javascript per l'integrazione di componenti reattivi, separando la competenza CSS da quella JS.