O que torna o BEM melhor do que usar uma linguagem de folha de estilos aninhada como LESS?

Um colega meu está pressionando fortemente o método BEM ( Modificador de elemento de bloco ) para o CSS em um projeto que ele está dirigindo, e eu simplesmente não consigo entender o que o torna melhor do que o MENOS CSS que escrevemos há anos.

Ele alega "desempenho superior", mas não consigo imaginar como o desempenho pode ser importante para os tipos de aplicativos da web que escrevemos nesta loja de códigos. Não estamos criando Twitter ou Facebook aqui. Eu ficaria muito surpreso se nossos aplicativos de maior uso tiverem mais de 10.000 acessos por mês e a maioria estiver bem abaixo de 1.000.

Ele afirma "legibilidade" e "reutilização", mas MENOS já faz isso muito melhor , na minha opinião. E sinto que o BEM manipula a marcação tão mal com dezenas de caracteres extras dedicados a esses nomes de classe super longos que reduz radicalmente a legibilidade.

Ele afirma que "CSS aninhado é um anti-padrão". O que significa "anti-padrão" mesmo média , e por que é aninhada ruim CSS?

Ele afirma que "todo mundo está caminhando para o uso do BEM, então devemos também". Meu contador é "Se todo mundo estivesse pulando de uma ponte, você seguiria?" Mas ele ainda é totalmente inflexível sobre isso.

Alguém poderia explicar em detalhes o que torna o BEM melhor que o MENOS? Meu colega não conseguiu me convencer completamente, mas não sei se tenho outra opção a não ser segui-lo. Eu realmente preferiria apreciar o BEM do que aceitá-lo de má vontade.

Um colega meu está pressionando fortemente o método BEM (Modificador de elemento de bloco) para o CSS em um projeto que ele está dirigindo, e eu simplesmente não consigo entender o que o torna melhor do que o MENOS CSS que escrevemos há anos.

BEM é uma metodologia CSS. Outros incluem OOCSS e SMACSS. Essas metodologias são usadas para escrever código modular, extensível e reutilizável, com bom desempenho em escala.

LESS é um pré-processador CSS. Outros incluem Sass e Stylus. Esses pré-processadores são usados ​​para converter suas respectivas fontes em CSS expandido.

O BEM e o MENOS não são comparáveis ​​por serem "melhores" do que o outro, são ferramentas que servem a propósitos diferentes. Você não diria que uma chave de fenda é melhor que um martelo, exceto quando considera a utilidade para resolver um problema específico.

Ele afirma "maior desempenho" ...

O desempenho precisaria ser medido entre um estilo CSS clássico de:

.widget .header

e estilo BEM de:

.widget__header

mas, de um modo geral, o desempenho do seletor de CSS não é um gargalo e não precisa ser otimizado.

O "desempenho" do BEM geralmente é referente ao código de gravação de desempenho de um desenvolvedor. Se a metodologia BEM for usada de forma consistente e correta, é fácil para grupos de desenvolvedores criarem simultaneamente módulos distintos sem colisões de estilo.

Ele afirma "legibilidade" e "reutilização" ...

Não sei se diria a um novo desenvolvedor que o BEM é mais legível. Posso dizer que ele fornece algumas diretrizes bem definidas quanto ao significado e estrutura das classes.

Vendo uma classe como

.foo--bar__baz

Diz-me que existe um foobloco que está no barestado e contém um bazelemento.

Eu diria absolutamente que o BEM é mais reutilizável que um modelo clássico.

Se dois desenvolvedores criam blocos ( fooe bar) e ambos têm títulos, eles podem reutilizar seus blocos com segurança em diferentes contextos sem se preocupar com uma colisão de nomes.

Isso porque, em um contexto clássico, .foo .headinge .bar .headingentraria em conflito, e introduzir um conflito especificidade que precisa ser resolvido, possivelmente numa base caso-a-caso.

Em um site do BEM, as classes seriam .foo__headinge .bar__heading, que nunca entrariam em conflito.

Ele afirma que "CSS aninhado é um anti-padrão". O que significa "antipadrão" e por que o CSS aninhado é ruim?

Um "antipadrão" é um padrão de codificação mais fácil para os desenvolvedores inexperientes aprenderem e usarem do que uma alternativa mais apropriada.

Quanto ao motivo pelo qual CSS aninhado é ruim: o aninhamento aumenta a especificidade de um seletor. Quanto maior a especificidade, mais esforço é necessário para substituir. Os desenvolvedores inexperientes geralmente se preocupam com o fato de o CSS afetar várias páginas, então eles usam seletores como:

#something .lorem .ipsum .dolor ul.sit li.amet a.more

Quando um desenvolvedor experiente teme que seu CSS não afete várias páginas, ele usa seletores como:

.more

Ele afirma que "todo mundo está se movendo para usar o BEM, então devemos também".

Isso é uma falácia do movimento , então ignore isso como um argumento ruim. Não caia na armadilha da falácia da falácia , porque um argumento ruim em apoio ao BEM não é uma razão para acreditar que o BEM não pode ser bom.

Alguém poderia explicar em detalhes o que torna o BEM melhor que o MENOS?

Eu cobri isso antes, BEM & LESS não são comparáveis. Maçãs e laranjas, etc.

Meu colega não conseguiu me convencer completamente, mas não sei se tenho outra opção a não ser segui-lo.

Eu recomendo dar uma olhada em OOCSS, SMACSS e BEM, e pesar os prós e contras de cada metodologia ... como uma equipe . Uso o BEM porque gosto do rigor no formato e não me importo com os seletores feios, mas não posso dizer o que é certo para você ou sua equipe. Não deixe que um indivíduo franco faça o show. Se você não estiver familiarizado com o BEM, saiba que existem outras alternativas que podem ser mais fáceis para sua equipe apoiar. Pode ser necessário defender sua posição com seu colega de trabalho, mas a longo prazo provavelmente terá um efeito positivo no resultado de seus projetos.

Eu realmente preferiria apreciar o BEM do que aceitá-lo de má vontade.

Eu escrevi uma resposta no StackOverflow que descreve como o BEM funciona . O importante é entender que seus seletores ideais devem ter uma especificidade de 0-0-1-0modo que sejam fáceis de substituir e estender.

Escolher usar o BEM não significa que você precisa desistir de MENOS! Você ainda pode usar variáveis, ainda pode usar @imports e certamente pode continuar usando o aninhamento. A diferença é que você deseja que a saída renderizada se torne uma classe única, em vez de uma cadeia descendente.

Onde você poderia ter

.widget {
    .heading {
        ...
    }
}

Com o BEM você pode usar:

.widget {
    &__heading {
        ...
    }
}

Além disso, como o BEM gira em torno de blocos individuais, é possível separar facilmente o código em arquivos separados. widget.lessconteria estilos para o .widgetbloco, enquanto component.lessque conteria estilos para o .componentbloco. Isso torna muito mais fácil encontrar a fonte para qualquer classe em particular, embora você ainda deseje usar os mapas de origem.

Edit 2017

Se você estiver lendo isso em 2017, os DOM de sombra e os polyfills DOM de sombra, além de componentes, resolvem todos esses problemas, mantendo seu código pequeno, rígido e modular. Não use o BEM em um projeto greenfield IMO.

Em vez do BEM, temos ferramentas como ViewEncapsulation, Polymer, StyledJSX, Módulos SASS, Styled Components, etc.

Considere usar o BEM se você não tiver uma arquitetura orientada a componentes; se você tiver código legado para oferecer suporte; ou se você está pronto para fazer tudo manualmente sem ferramentas.

O BEM torna seu estilo independente do seu aninhamento DOM. Isso é feito fornecendo a todos os elementos que você pode querer estilizar um atributo de classe imbecil que provavelmente será exclusivo em sua página. A maioria dos estilos é feita nas aulas.

Isso torna seu código mais modular, porque o aninhamento não é mais levado em consideração, à custa de muita verbosidade.

Sem BEM

Sem o BEM, podemos escrever o seguinte:

<div class="widget">
  <a>Hello!</a>
  <ul>...</ul>
</div>

O estilo CSS padrão pode ficar assim:

.widget {
  border: 1px solid red;
}

.widget a {
  color: green;
}

A mesma coisa com o SASS ficaria assim:

.widget {
  border: 1px solid red;
  a {
    color: green;
  }
}

Se você é uma equipe pequena, na qual todos podem codificar CSS com um alto padrão, e o projeto é pequeno o suficiente para que você possa manter o conhecimento completo, essa é uma solução boa e razoável.

Com o BEM

No entanto, se o seu código se tornar maior e você tiver uma equipe grande de habilidades mistas, isso pode não ser uma solução tão simples. E se você quiser âncoras verdes em outro widget, por exemplo. Por isso, modificamos a âncora e eliminamos os seletores descendentes.

Agora nosso HTML é muito mais detalhado:

<div class="widget">
  <a class="widget__anchor">Hello!</a>
  <ul class="widget__ul">...</ul>
</div>

Nosso CSS não tem seletores descendentes:

.widget {
  border: 1px solid red;
}

.widget__anchor {
  color: green;
}

Mas agora podemos fazer isso:

<div class="widget__2">
  <a class="widget__anchor">Hello!</a>
</div>

O widget__anchor é modular. É improvável que outra definição de .widget__anchor exista na página.

tradeoffs:

BEM:

• Fornece código mais modular. Você pode pegar qualquer peça isoladamente.
• Permite que alguém escreva CSS. Você não precisa estar ciente do estilo principal e das substituições personalizadas. Em uma equipe grande, isso é legal.
• Remove quaisquer problemas de especificidade.
• É significativamente mais detalhado.

CSS padrão (que se baseia no uso de seletores descendentes):

• Significa que seu estilo depende do contexto.
• Requer uma consciência da cascata. O código em um único local pode afetar o código em outro lugar. Em uma equipe pequena, isso é uma coisa boa.
• Pode sofrer de problemas de especificidade que podem ser difíceis para um desenvolvedor iniciante depurar.
• É significativamente mais apertado.

A terceira maneira - componentes reais.

Se você estiver usando algo como React, Angular 2 ou qualquer outra palavra de estrutura moderna de front-end, terá outra solução. Você pode usar ferramentas para impor o encapsulamento.

Este exemplo usa React e StyledJSX, mas há muitas opções. Aqui está um widget:

const Widget = () => 
  <div>
    <a>Hello</a>
  </div>
  <style jsx>
    div {border:red }
    a { background: pink }
  </style>

Você usaria o novo widget como este:

<Widget />

Todos os estilos declarados no widget seriam encapsulados e não se aplicariam a elementos fora do componente. Somos livres para simplesmente estilizar o dive o adiretamente, sem nos preocupar em estilizar acidentalmente qualquer outra coisa na página.

Nenhuma abordagem é perfeita. IMHO, devemos obter as melhores partes de cada uma das metodologias (BEM, SMACSS, OOCSS, DRY). Use o SMACSS para organizar sua estrutura de pastas no seu CSS, especialmente para definir a divisão do nível lógico de todo o CSS. SECA para criar sua biblioteca de utilitários ou pode ser uma biblioteca modificadora comum que pode ser usada algumas vezes em conjunto com classes baseadas no BEM. OOCSS para componentes. E BEM para pequenos componentes ou subcomponentes. Lá, você pode distribuir a complexidade e obter liberdade para trabalhar em uma grande equipe.

Qualquer coisa quando usada sem entender a essência dela resultará ruim.

Embora o BEM seja uma boa abordagem para equipes maiores, ele também apresenta algumas desvantagens. 1. Às vezes, resulta em nomes muito longos na grande estrutura HTML. Grande tamanho de arquivo CSS resultante. 2. Para aninhar htmls com mais de 2-3 níveis, torna-se uma dor de cabeça para definir nomes.

A resolução de conflitos pode ser facilmente gerenciada se pensarmos na estrutura dos componentes, juntamente com um conjunto muito básico de estilo base. É apenas uma herança de dois níveis. Todo elemento dentro de um componente teria uma regra de estilo global ou específica para esse componente. Essa é uma das opções mais fáceis.