Skip to content
This repository has been archived by the owner on May 20, 2022. It is now read-only.

Scelte tecniche

Danilo Spinelli edited this page Oct 11, 2016 · 10 revisions

Perchè PostCSS e non Sass

  1. L'utilizzo di Sass è spesso accoppiato a quello di PostCSS (autoprefixer e/o cssnano) pertanto la scelta è stata escludere Sass per semplificare lo stack risparmiando una tecnologia
  2. È possibile utilizzare PostCSS con la sintassi di Sass
  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 componenti; è una libreria di classi di utilità che possono o meno esser utilizzate. In questo modo i componenti possono essere definiti in maniera totalmente autonoma
  2. La longevità di una utility-class è 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 rigide regole 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 Tachyons o BassCSS nonché l'utilizzo di stili inline o CSS modules per framework Javascript quali React

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

  1. Molte tra le problematiche segnalate nell'articolo Why You Should Avoid Sass @extend non si verificano utilizzando il corrispondente plugin di PostCSS.
  2. Il resto delle problematiche è risolto limitando l'utilizzo di @extend alle sole classi di utilità, il che ne scongiura gli effetti collaterali (ref. https://marvelapp.com/styleguide/overview/introduction)
  3. Solo tramite @extend è possibile riutilizzare le classi di utilità all'interno del CSS; ciò risulta particolarmente significativo per il riuso delle classi responsive (es. tipografia, margini e padding)