LESS e Sass mirano a realizzare la stessa cosa, e sono davvero così simili da poter facilmente confondere i due, ma sono veramente creati uguali? C'è qualcosa che si può fare che l'altro non può?
Su una funzione caratteristica, ogni sintassi ha una o due cose che l'altra no. Tuttavia, nonostante fossi inizialmente attratto dalla semplicità di LESS, alla lunga non ho potuto fare a meno di essere risucchiato da alcune caratteristiche chiave che rendono Sass davvero potente. Seguiteci mentre vi soffio la mente con alcune delle straordinarie e uniche caratteristiche di Sass.
MENO vs Sass
Sia Sass che LESS sono in circolazione da un po 'di tempo ma sembra che abbiano raggiunto il successo nel 2011 e abbiano guadagnato molta popolarità. Entrambi offrono eccellenti modi per estendere i CSS per essere più programmabili, il che porta a un codice più logico e conciso che utilizza molto meno ripetizioni.
Chi è più amichevole?
Recentemente qui su Design Shack ho prestato molta attenzione a LESS. Certo, trovo che sia la più accessibile delle due opzioni. Alcuni discutono contro questa nozione fino a quando non sono blu in faccia, ma resta il semplice fatto che LESS ha una configurazione davvero bella: usa un semplice file .js per testare e compilare il codice automaticamente con un'app user-friendly: Meno. app.
Non importa quanto pensi che ogni sviluppatore CSS dovrebbe conoscere Ruby ed essere un mago di Terminale, la realtà è che molti non si adattano affatto a questa descrizione e preferiscono trascorrere la giornata imparando una cosa (MENO) invece di due (Sass + come funzionano le gemme Ruby).
Certo, Sass richiede solo un piccolissimo uso del terminale che praticamente chiunque può gestire, ma sarete sorpresi di quante persone sono state allontanate a causa di questo.
Non così in fretta
Di recente però, questo paesaggio è cambiato in modo drammatico. Stanno emergendo soluzioni come CodeKit che rendono la scrittura Sass e l'output di CSS altrettanto semplice come usare Sass.
In effetti, CodeKit compila automaticamente i file LESS, Sass, Stylus e CoffeeScript. Tutto quello che devi fare è inserire la cartella del tuo progetto e il tuo lavoro è finito. Così tanto per MENO essere più amichevole!
Chi è più potente?
Per molti sviluppatori, l'argomento su cui è più facile implementare è abbastanza meschino considerando che sia LESS che Sass sono abbastanza semplici da usare. Il vero argomento poi scende al potere: quale linguaggio può fare di più?
La risposta non è terribilmente semplice. Si scopre che sia LESS che Sass hanno caratteristiche uniche non condivise dall'altra. Tuttavia, bisogna dire che in questa zona, Sass tira fuori davvero dei colpi impressionanti. Diamo un'occhiata a due dei miei preferiti: strutture @extend e di controllo.
Sass @extend
Ogni volta che dico qualcosa su LESS, i ragazzi del campo di Sass iniziano a delirare sul comando di Sass '@extend. Si scopre, c'è una buona ragione per questo: in realtà è piuttosto pericoloso.
La magia dietro a @extend è che ti permette di disegnare selettori che agiscono su altri selettori e prendono in prestito le loro proprietà. Diciamo che stavi disegnando un blog e volevi due diversi set di stili: un set per un commento e un altro per ogni risposta a quel commento. Il tuo stile per ognuno sembra quasi identico, con alcune eccezioni:
In alternativa, è possibile utilizzare solo il? .Reply? classe per i diversi stili, ma questo richiederebbe l'applicazione di entrambi ?. e? .reply? classi per la tua risposta HTML div. Quindi, come possiamo mantenere la nostra marcatura sottile, ma rendere questo codice meno ripetitivo?
Con Sass '@extend, questo processo è semplicissimo. Una volta impostato il nostro selettore iniziale, digitiamo semplicemente? @Extend? più il nome del selettore che vogliamo rubare e tutto il codice relativo al primo selettore verrà applicato al secondo. Da qui possiamo quindi entrare e applicare le nostre eccezioni, aggiunte, ecc.
Nota che stiamo usando la più recente sintassi .scss.
Output CSS
L'output di questo comando @extend è bello e pulito e rappresenta in realtà come dovremmo aver codificato il nostro CSS in primo luogo. Sass trova automaticamente le proprietà condivise e uniche e imposta ciascuna ai selettori appropriati.
Quindi, perché non farlo in primo luogo? Ottima domanda! Potresti in effetti fare proprio questo. Tuttavia, la sintassi di Sass rappresenta un processo di pensiero leggermente più lineare che è più facile per alcuni di avvolgere la loro mente.
Tieni presente che questo è un esempio troppo semplificato, se lavorassi con un enorme progetto con tonnellate di selettori, i vantaggi di Sass sarebbero ancora più evidenti.
Andare avanti
Promuovendo la sua utilità, il comportamento di @extend può gestire un bel po 'di complessità.Ad esempio, è possibile utilizzare più estensioni su un singolo selettore:
Puoi anche concatenare @extends. Questo ti permette di costruire gradualmente livelli di complessità in un modo facile da capire.
Come potete vedere, questo è in realtà un po 'più semplice da interpretare rispetto al modulo CSS compilato, che è meravigliosamente sintetico ma può essere un po' confuso.
Per saperne di più su Sass @extends, controlla la documentazione ufficiale dal sito Web di Sass.
Direttive di controllo
Il comando Sass @extend è sicuramente un argomento killer per andare con Sass su LESS. È super utile e aiuta a mantenere il tuo complesso CSS scintillante pulito, organizzato e facile da leggere.
Tuttavia, su scala pazzesca, il punteggio @extends è piuttosto basso. Se vuoi veramente vedere dove la gente di Sass è scappata in un territorio abbozzato, dovresti controllare le direttive di controllo, che inseriscono alcuni costrutti di programmazione seri nei CSS.
Tutti voi fan dell'hardcore di puro CSS che non sono sicuri su Sass in primo luogo, sicuramente non vi piacerà quello che state per vedere. Tuttavia, quelli di noi che sono aperti a divertirsi con i CSS e amano già programmare, questo diventa davvero interessante.
Non per lo stile giorno per giorno
Se dai uno sguardo agli esempi qui sotto e decidi che sembrano troppo complicati da usare nei tuoi progetti, probabilmente hai ragione. Arrivano con questo avvertimento direttamente dagli sviluppatori di Sass:
? Si noti che le direttive di controllo sono una funzionalità avanzata e non sono raccomandate nel corso della progettazione quotidiana. Esistono principalmente per l'uso in mix, in particolare quelli che fanno parte di librerie come Compass, e quindi richiedono una notevole flessibilità.
Se le dichiarazioni
Se non avessi mai pensato di vedere il giorno in cui le dichiarazioni e i CSS si incontrassero, ti sbagliavi. Sass supporta la funzionalità di base if / else e la compila nei CSS. Ad esempio, nell'esempio seguente, vogliamo che il colore del testo sia nero in tutti i casi tranne quelli in cui il colore di base è già nero, quindi lo abbiamo impostato su bianco.
Quindi, diciamo che utilizziamo questo frammento in alcuni modelli che abbiamo impostato altrove e importiamo quel modello nel nostro nuovo file di progetto. Se in qualsiasi momento impostiamo il colore di base su nero come questo?
il nostro CSS compilato imposterà il colore del paragrafo in bianco.
Se d'altra parte, la variabile di base-colore è impostata su qualcos'altro?
il colore del paragrafo verrà automaticamente impostato su nero.
@for Loop
Oltre alle istruzioni if, Sass supporta i loop. Ad esempio, supponiamo di voler creare quattro classi di colonne che aumentino gradualmente di larghezza. Invece di digitare manualmente ogni classe, possiamo risparmiare molto lavoro semplicemente impostando un ciclo for semplice.
Questa dichiarazione verrà compilata nel seguente CSS:
Notate come ha usato il? $ I? contatore per aumentare il numero aggiunto al nome della classe ogni volta e quindi aumentare la larghezza moltiplicando la corrente? $ i? valore di dieci pixel.
@while Loop
Molti linguaggi di programmazione supportano diversi stili di loop, quindi Sass ne segue l'esempio includendo non solo un? For? struttura ma un? mentre? struttura pure. Questa volta, diciamo che vogliamo costruire le classi Grid 1 Kb usando Sass. Ecco come lo faresti:
Questa istruzione si ripete dodici volte, creando classi .grid con nomi che aumentano di un'unità ogni volta e impostano le classi su una larghezza che aumenta di 80 px ogni volta. Questo piccolo frammento di CSS viene compilato per questa grande porzione di codice:
@ogni
La struttura di controllo finale è @each, che consente di elencare in modo conciso un set di variabili da distribuire su una porzione più ampia di codice. Ad esempio, supponiamo di voler creare alcune classi che utilizzano famiglie di font differenti, potresti fare qualcosa di simile al seguente:
Questo verrà compilato nel CSS qui sotto.Il risultato sono tre classi separate che utilizzano i tre nomi di carattere che abbiamo inserito nella prima riga in alto.
Ancora una volta, per saperne di più sulle direttive di controllo, dovresti assolutamente dare un'occhiata alla documentazione ufficiale. C'è un bell'esempio @each che usa i nomi delle immagini al posto dei font. È più utile e pratico del mio esempio precedente, ma volevo illustrare una possibilità diversa.
Prima che ti lamenti?
L'ovvio argomento contro l'uso di questi è che sono direttamente in violazione dei miei argomenti per un codice di facile lettura. Questi ti fanno risparmiare tempo di battitura, ma richiedono un'interpretazione piuttosto pesante, abbastanza da far girare la testa a volte. Tieni presente, tuttavia, che la gente di Sass li consiglia soprattutto per l'uso in mix, che a loro volta possono ancora contribuire a semplificare il codice a causa della loro natura riutilizzabile.
Ammetto che probabilmente è meglio evitare le strutture di controllo dove possibile, ma non posso fare a meno di entusiasmarmi per il fatto che Sass include questi, avvisi o no. Parlano davvero della potenza della sintassi e di quanto sia impegnato il team di Sass a renderlo uno strumento di sviluppo web estremamente avanzato e unico.
Conclusione
Questa non è affatto una discussione esauriente sui vantaggi di Sass rispetto a LESS, ma è un po 'strano vedere le due aree che ho trovato essere le più impressionanti e interessanti. Entrambe le strutture @extend e control forniscono agli sviluppatori alcuni strumenti potenti che semplicemente non trovi altrove. Allo stesso modo, LESS ha qualche asso nella manica, come Namespace, che non troverai in Sass.
In definitiva, se usi Sass o LESS non dovrebbe importare troppo. Si riduce a una questione di opinioni e se ti piace uno migliore dell'altro, non dovresti davvero sentirti dire che è qualcosa su cui discutere. Se prendo la via Sass e prendi la rotta LESS, entrambi i nostri siti web dovrebbero comunque contenere un puro file CSS alla fine (dovresti sempre compilare prima di caricare). Perché dovrei preoccuparmi che il percorso che hai preso per arrivarci fosse diverso dal mio? Finché il tuo codice risultante è valido e ben strutturato, è buono come il mio.
Detto questo, sono ansioso di sentire quale sintassi preferisci. Per quanto mi riguarda, sono abbastanza a mio agio ad usare entrambi. Ad essere onesti, però, ho iniziato con fermezza nel campo LESS, ma recentemente sono stato davvero attratto da una parte della potenza che Sass presenta in funzioni come quelle sopra.
Cosa pensi? Con strumenti come CodeKit che rendono entrambe le sintassi così facilmente accessibili, quali sono le tue ragioni per usare l'una sull'altra?