Scelte tecniche

Perchè PostCSS e non Sass

1. L'utilizzo di Sass è spesso in tandem con quello di PostCSS (autoprefixer e/o cssnano); pertanto si è scelto di escludere Sass per semplificare lo stack risparmiando una tecnologia
2. È possibile utilizzare PostCSS con la sintassi di Sass (https://github.com/jonathantneal/precss)
3. Tuttavia è stato ritenuto opportuno non farlo (es. lasciando fuori i mixin) e utilizzare invece una sintassi più vicina ai prossimi standard CSS (es. variabili custom) con un approccio future-proof (http://cssnext.io/). È ipotizzabile fare a meno di qualche plugin quando il supporto dei browser sarà migliore

Perchè SuitCSS

1. SuitCSS non è un framework di component; è una libreria di classi di utilità che possono o meno esser utilizzate. in tal modo i componenti possono essere definiti in maniera totalmente autonoma
2. La longevità di una classe di utilità (introdotte anche in Bootstrap4) è superiore a quella delle classi per i componenti: è probabile che una classe del tipo u-floatLeft { float: left; } non sarà mai rifattorizzata e laddove dovesse accadere è ipotizzabile poterla mantenere internamente
3. A differenza di Bootstrap SuitCSS ha delle regole rigide di nomenclatura, il che facilita la collaborazione senza "interferenze" limitando nel contempo il CSS globale (le classi sono tutte in opt-in)

Ci sono troppe classi nell'HTML, non è semantico !

1. La semantica dell'HTML riguarda l'utilizzo corretto dei tag (es. section o nav al posto di div) e non le classi applicate agli elementi; i nomi delle classi veicolano un'informazione per gli sviluppatori, non servono alle macchine né agli utenti
2. Attingere a un parco di classi di utilità è senza ombra di dubbio utile, tant'è che sono state introdotte anche in Bootstrap4, una tendenza che va di pari passo con l'affermarsi di framework quali http://tachyons.io/ o http://www.basscss.com/

L'utilizzo della direttiva @extend non è una bad-practice ?