SASS: annidare o non annidare?

Brad Frost, sviluppatore web di Pittsburgh, ha lanciato su Twitter un'interessante domanda dedicata ai designer CSS ed in particolare agli utilizzatori del motore SASS: nella fase di definizione dei selettori, è preferibile annidarli, oppure no?

Vediamo nello specifico un semplice snippet che mostra entrambi gli approcci.

Il primo, mostra selettori CSS non annidati:

.c-btn {
// regole css
}
.c-btn__icon
{
// regole css
}

Il secondo snippet esegue il medesimo compito utilizzando uno stile di dichiarazione differente, l'annidamento dei selettori:

.c-btn {
   &__icon {
      // regole css
   }
}

Uno sviluppatore CSS moderno deve necessariamente essere in grado di comprendere entrambi gli stili di scrittura, e soprattutto riprodurli in contesti anche più avanzati. Ma vediamo quali vantaggi e svantaggi offrono entrambi gli approcci.

Senza annidamento

Non utilizzare l'annidamento presenta i seguenti vantaggi:

1. Maggiore grado di reperibilità. Uno dei più evidenti vantaggi di scrivere codice CSS senza annidare i selettori nella modalità offerta da SASS risiede nel fatto che il selettore stesso è facilmente "reperibile" nel codice sorgente. Se nel markup HTML ci imbattiamo nella classe c-btn__icon, sarà sufficiente ricercare (CTRL+F) nel CSS la medesima classe per giungere al selettore specifico.
2. Maggiore leggibilità. Molti utenti sottolineano la maggiore leggibilità del selettore classico, specialmente se incluso in un codice molto complesso.
3. Non è dipendente da SASS. Questo approccio non è basato sul preprocessore SASS, ma si avvale unicamente del CSS classico. Per molti (almeno la metà degli sviluppatori CSS) dipendere da un preprocessore CSS non è una scelta vincente.
4. Alleggerire SASS. SASS offre una modalità fantastica per scrivere CSS. Tuttavia, dato che da grandi poteri derivano grandi responsabilità, è facile abusare della sintassi di SASS producendo codice illeggibile. Meglio utilizzare l'annidamento per i casi veramente necessari, come ad esempio i pseudo-stati e le media-query.

I principali svantaggi di questo approccio sono invece i seguenti:

1. No DRY (Don't Repeat Yourself). La voce dice tutto: con questo approccio è necessario ripetere il selettore, e questa situazione si ripete per tutti i possibili sottoselettori. Oltre ad una quantità di tempo maggiore, allo sviluppatore servirà anche un maggior grado di attenzione agli errori di scrittura.
2. Prolissità. Più il codice è lungo, più è prolisso. Un bersaglio facile per quella schiera di sviluppatori che sostiene il "write less, do more".

Con annidamento

Di contro a quanto sopra descritto, l'annidamento ha i seguenti vantaggi:

1. Yes DRY. In questo caso il design pattern Don't Repeat Yourself viene rappresentato in modo efficace. Se malauguratamente occorre cambiare il nome del selettore, non ci sarà occorrenza di riflettere il cambiamento in ogni sotto-selettore. DRY, appunto.
2. Risparmio di tempo. Questa è una caratteristica ricercata da quasi tutti gli sviluppatori web e/o programmatori: scrivere meno codice significa guadagnare tempo da spendere per altre parti dell'applicazione. Inoltre, molti sviluppatori sostengono che la leggibilità del codice sia comunque adeguata, una volta nell'ottica delle dinamiche SASS.

Gli svantaggi dell'approccio basato sull'annidamento sono invece i seguenti:

1. Meno reperibilità. Contrariamente a quento dichiarato nei vantaggi del primo approccio, ricercare meccanicamente un selettore CSS utilizzando l'annidamento dei selettori risulta complicato, se non impossibile.
2. Smarrimento del contesto. Non è certamente il caso offerto da Brad, ma in un'ottica CSS molto più complessa, l'annidamento dei selettori può far perdere l'orientamento allo sviluppatore, allontanandolo dal contesto iniziale.
3. Abuso dei propri poteri. Ancora una volta, da grandi poteri derivano grandi responsabilità. Da un preprocessore CSS derivano grandi poteri, e dunque grandi responsabilità. Così come le tabelle sono state abusate all'epoca per produrre layout, c'è il rischio che gli annidamenti vengano abusati anche quando non è necessario. Meglio tenere un equilibrio anche utilizzando i preprocessori: la qualità del codice ne avrà enormi benefici.