A colleague of mine is heavily pushing the BEM (Block Element Modifier) method for the CSS in a project he's helming, and I just cannot comprehend what makes it better than the LESS CSS we've been writing for years.
BEM è una metodologia CSS. Altri includono OOCSS e SMACSS. Queste metodologie vengono utilizzate per scrivere codice modulare, estensibile e riutilizzabile che funzioni bene su scala.
LESS è un preprocessore CSS. Altri includono Sass e Stilo. Questi preprocessori sono usati per convertire le rispettive fonti in CSS espansi.
BEM e LESS non sono paragonabili come "migliori" degli altri, sono strumenti che servono a scopi diversi. Non diresti che un cacciavite è meglio di un martello, tranne quando consideri l'utilità per risolvere un problema specifico.
He claims "higher performance"...
Le prestazioni dovrebbero essere misurate tra uno stile CSS classico di:
.widget .header
e lo stile BEM di:
.widget__header
ma in generale, le prestazioni del selettore CSS non sono un collo di bottiglia e non devono essere ottimizzate.
La "prestazione" BEM è solitamente in relazione al codice di scrittura delle prestazioni di uno sviluppatore. Se la metodologia BEM viene utilizzata in modo coerente e corretto, è facile per gruppi di sviluppatori creare simultaneamente moduli distinti senza conflitti di stile.
He claims "readability" and "re-use"...
Non so che direi a un nuovo sviluppatore che BEM è più leggibile. Posso dire che fornisce alcune linee guida ben definite sul significato e sulla struttura delle classi.
Vedendo una classe come
.foo--bar__baz
Mi dice che esiste un blocco foo che si trova nello stato bar e contiene un elemento baz .
Direi assolutamente che il BEM è più riutilizzabile di un modello classico.
Se due sviluppatori creano blocchi ( foo e bar ), e entrambi i blocchi hanno intestazioni, possono riutilizzare i blocchi in modo sicuro in diversi contesti senza preoccuparsi di una collisione di nomi.
Questo perché, in un contesto classico, .foo .heading e .bar .heading entrerebbero in conflitto e introdurrebbe un conflitto di specificità che dovrebbe essere risolto, eventualmente caso per caso.
In un sito BEM, le classi sarebbero .foo__heading e .bar__heading , che non sarebbero mai in conflitto.
He claims "nested CSS is an anti-pattern." What does "anti-pattern" even mean, and why is nested CSS bad?
Un "anti-pattern" è un pattern di codifica che è più semplice da imparare per gli sviluppatori inesperti rispetto a un'alternativa più appropriata.
Per quanto riguarda il motivo per cui CSS annidato è sbagliato: l'annidamento aumenta la specificità di un selettore. Maggiore è la specificità, maggiore è lo sforzo necessario per eseguire l'override. Gli sviluppatori inesperti temono spesso che il loro CSS possa influenzare più pagine, quindi usano selettori come:
#something .lorem .ipsum .dolor ul.sit li.amet a.more
Quando uno sviluppatore esperto si preoccupa che i suoi CSS non possano influenzare più pagine, quindi usano selettori come:
.more
He claims that "everyone is moving toward using BEM, so we should too."...
Questa è una fallacia del carro da guerra , quindi ignorala come una brutta discussione. Non cadere nella trappola della fallacia fallacia , perché un argomento non valido a sostegno del BEM non è un motivo per credere che BEM non può essere buono.
Could someone please explain in detail what makes BEM better than LESS?
Ne ho parlato prima, BEM & MENO non sono paragonabili. Mele e arance, ecc.
My colleague is completely failing to convince me, but I don't know if I have a choice but to follow.
Raccomando di dare un'occhiata a OOCSS, SMACSS e BEM e a valutare i pro e i contro di ogni metodologia ... come una squadra . Uso BEM perché mi piace il suo rigore nel formato e non mi importa dei brutti selezionatori, ma non posso dirti cosa è giusto per te o per la tua squadra. Non lasciare che un individuo schietto faccia lo spettacolo. Se non ti senti a tuo agio con BEM, tieni presente che esistono altre alternative che potrebbero essere più facili da supportare per il tuo team. Potrebbe essere necessario difendere la tua posizione con il tuo collega, ma a lungo termine avrà probabilmente un effetto positivo sul risultato dei tuoi progetti.
I'd really rather be able to appreciate BEM, than to grudgingly accept it.
Ho scritto una risposta su StackOverflow che descrive come funziona BEM . La cosa importante da capire è che i tuoi selettori ideali dovrebbero avere una specificità di 0-0-1-0 in modo che siano facili da sovrascrivere ed estendere.
Scegliere di usare BEM non significa che devi rinunciare a MENO! Puoi ancora usare le variabili, puoi ancora usare @imports e puoi certamente continuare a usare il nesting. La differenza è che vuoi che l'output renderizzato diventi una singola classe, piuttosto che una catena discendente.
Dove potresti aver avuto
.widget {
.heading {
...
}
}
Con BEM puoi usare:
.widget {
&__heading {
...
}
}
Inoltre, poiché BEM ruota intorno a singoli blocchi, puoi facilmente separare il codice in file separati. widget.less conterrebbe gli stili per il blocco .widget , mentre component.less conterrà gli stili per il blocco .component . Questo rende molto più facile trovare la fonte per ogni particolare classe, sebbene tu possa ancora voler utilizzare le mappe sorgente.