¿Qué hace que BEM sea mejor que usar un lenguaje de hoja de estilo anidable como LESS?

Un colega mío está presionando fuertemente el método BEM ( Modificador de elemento de bloque ) para el CSS en un proyecto que está dirigiendo, y simplemente no puedo entender qué lo hace mejor que el MENOS CSS que hemos estado escribiendo durante años.

Afirma "mayor rendimiento", pero no puedo imaginar cómo el rendimiento podría importar incluso para los tipos de aplicaciones web que escribimos en esta tienda de códigos. No estamos haciendo Twitter o Facebook, aquí. Me sorprendería mucho si nuestras aplicaciones de mayor uso tienen más de 10000 visitas al mes , y la mayoría tienen menos de 1000.

Afirma "legibilidad" y "reutilización", pero MENOS ya lo hace mucho mejor , en mi opinión. Y siento que BEM desbarata tanto el marcado con docenas de caracteres adicionales dedicados a estos nombres de clase súper largos que reduce radicalmente la legibilidad.

Afirma que "CSS anidado es un antipatrón". ¿Qué significa incluso "antipatrón" y por qué el CSS anidado es malo?

Afirma que "todos se están moviendo hacia el uso de BEM, por lo que nosotros también deberíamos". Mi contador es "Si todos saltaran de un puente, ¿me seguirías?" Pero todavía es totalmente inflexible sobre esto.

¿Podría alguien explicar en detalle qué hace que BEM sea mejor que LESS? Mi colega no logra convencerme por completo, pero no sé si tengo otra opción que seguir. Realmente preferiría poder apreciar BEM, que aceptarlo a regañadientes.

Un colega mío está presionando fuertemente el método BEM (Modificador de elemento de bloque) para el CSS en un proyecto que está dirigiendo, y simplemente no puedo entender qué lo hace mejor que el MENOS CSS que hemos estado escribiendo durante años.

BEM es una metodología CSS. Otros incluyen OOCSS y SMACSS. Estas metodologías se utilizan para escribir código modular, extensible y reutilizable que funcione bien a escala.

LESS es un preprocesador de CSS. Otros incluyen Sass y Stylus. Estos preprocesadores se utilizan para convertir sus respectivas fuentes en CSS expandido.

BEM y LESS no son comparables como "mejores" entre sí, son herramientas que sirven para diferentes propósitos. No diría que un destornillador es mejor que un martillo, excepto cuando se considera la utilidad para resolver un problema específico.

Afirma "mayor rendimiento" ...

El rendimiento debería medirse entre un estilo CSS clásico de:

.widget .header

y estilo BEM de:

.widget__header

pero en general, el rendimiento del selector CSS no es un cuello de botella y no necesita ser optimizado.

El "rendimiento" BEM generalmente se refiere al código de escritura de rendimiento de un desarrollador. Si la metodología BEM se usa de manera consistente y correcta, es fácil para los grupos de desarrolladores crear simultáneamente módulos distintos sin colisiones de estilo.

Afirma "legibilidad" y "reutilización" ...

No sé si le diría a un nuevo desarrollador que BEM es más legible. Puedo decir que proporciona algunas pautas bien definidas en cuanto al significado y la estructura de las clases.

Ver una clase como

.foo--bar__baz

Me dice que hay un foobloque que está en el barestado y contiene un bazelemento.

Absolutamente diría que BEM es más reutilizable que un modelo clásico.

Si dos desarrolladores crean bloques ( fooy bar), y ambos bloques tienen encabezados, pueden reutilizar sus bloques de manera segura en diferentes contextos sin preocuparse de una colisión de nombres.

Eso es porque, en un contexto clásico, .foo .headingy .bar .headingentraría en conflicto, e introducir un conflicto especificidad que tendría que ser resueltos, posiblemente sobre una base de caso por caso.

En un sitio BEM, las clases serían .foo__headingy .bar__heading, lo que nunca entraría en conflicto.

Afirma que "CSS anidado es un antipatrón". ¿Qué significa incluso "antipatrón" y por qué el CSS anidado es malo?

Un "antipatrón" es un patrón de codificación que es más fácil de aprender y usar para los desarrolladores sin experiencia que una alternativa más apropiada.

En cuanto a por qué el CSS anidado es malo: el anidamiento aumenta la especificidad de un selector. Cuanto mayor sea la especificidad, más esfuerzo se necesita para anular. Los desarrolladores sin experiencia a menudo se preocupan de que su CSS pueda afectar a varias páginas, por lo que usan selectores como:

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

Cuando un desarrollador experimentado se preocuparía de que su CSS no afecte a varias páginas, entonces usa selectores como:

.more

Afirma que "todos se están moviendo hacia el uso de BEM, así que nosotros también deberíamos"

Esa es una falacia del carro , así que ignórela como un mal argumento. No caigas en la trampa de la falacia , porque un mal argumento en apoyo de BEM no es una razón para creer que BEM no puede ser bueno.

¿Podría alguien explicar en detalle qué hace que BEM sea mejor que LESS?

Cubrí esto antes, BEM y MENOS no son comparables. Manzanas y naranjas, etc.

Mi colega no logra convencerme por completo, pero no sé si tengo otra opción que seguir.

Recomiendo echar un vistazo a OOCSS, SMACSS y BEM, y sopesar los pros y los contras de cada metodología ... como equipo . Uso BEM porque me gusta su rigurosidad en el formato, y no me importan los selectores feos, pero no puedo decirte qué es lo correcto para ti o para tu equipo. No dejes que una persona abierta dirija el espectáculo. Si no se siente cómodo con BEM, tenga en cuenta que existen otras alternativas que podrían ser más fáciles de apoyar para su equipo. Es posible que deba defender su posición con su compañero de trabajo, pero a largo plazo probablemente tendrá un efecto positivo en el resultado de sus proyectos.

Realmente preferiría poder apreciar BEM, que aceptarlo a regañadientes.

Escribí una respuesta en StackOverflow que describe cómo funciona BEM . Lo importante que debe comprender es que sus selectores ideales deben tener una especificidad 0-0-1-0para que sean fáciles de anular y ampliar.

¡Elegir usar BEM no significa que deba renunciar MENOS! Todavía puede usar variables, aún puede usar @imports, y ciertamente puede continuar usando la anidación. La diferencia es que desea que la salida representada se convierta en una sola clase, en lugar de una cadena descendiente.

Donde podrías haber tenido

.widget {
    .heading {
        ...
    }
}

Con BEM puedes usar:

.widget {
    &__heading {
        ...
    }
}

Además, debido a que BEM gira en torno a bloques individuales, puede separar fácilmente el código en archivos separados. widget.lesscontendría estilos para el .widgetbloque, mientras component.lessque contendría estilos para el .componentbloque. Esto hace que sea mucho más fácil encontrar el origen de cualquier clase en particular, aunque es posible que aún desee utilizar mapas de origen.

Editar 2017

Si está leyendo esto en 2017, los polyfills shadow DOM y shadow DOM, además de los componentes, resuelven todos estos problemas, mientras mantienen su código pequeño, ajustado y modular. No use BEM en un proyecto greenfield IMO.

En lugar de BEM, tenemos herramientas como ViewEncapsulation, Polymer, StyledJSX, SASS Modules, Styled Components, etc.

Considere usar BEM si no tiene una arquitectura orientada a componentes; si tiene un código heredado que admitir; o si simplemente está decidido a hacer todo manualmente sin herramientas.

BEM hace que su estilo sea independiente de su anidamiento DOM. Para ello, le da a cada elemento que desee un estilo un atributo de clase grande que probablemente sea único en su página. La mayoría del estilo se realiza en las clases.

Esto hace que su código sea más modular, ya que la anidación ya no se tiene en cuenta, a expensas de una gran cantidad de verbosidad.

Sin BEM

Sin BEM, podríamos escribir esto:

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

El estilo CSS estándar podría verse así:

.widget {
  border: 1px solid red;
}

.widget a {
  color: green;
}

Lo mismo con SASS se vería así:

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

Si eres un equipo pequeño donde todos pueden codificar CSS con un alto estándar, y el proyecto es lo suficientemente pequeño como para que puedas mantener un conocimiento completo de él, esta es una solución buena y razonable.

Con BEM

Sin embargo, si su código se hace más grande y tiene un gran equipo de habilidades mixtas, esta podría no ser una solución tan simple. ¿Qué pasa si quieres anclas verdes en otro widget, por ejemplo? Entonces hacemos el ancla modular y eliminamos los selectores descendientes.

Ahora nuestro HTML es mucho más detallado:

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

Nuestro CSS no tiene selectores descendientes:

.widget {
  border: 1px solid red;
}

.widget__anchor {
  color: green;
}

Pero ahora podemos hacer esto:

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

El widget__anchor es modular. Es poco probable que exista otra definición de .widget__anchor en la página.

compensaciones:

BEM:

• Te da más código modular. Puedes tomar cualquier pieza de forma aislada.
• Permite que cualquiera escriba CSS. No necesita tener en cuenta el estilo maestro y las anulaciones personalizadas. En un equipo grande, esto es bueno.
• Elimina cualquier problema de especificidad.
• Es significativamente más detallado.

CSS estándar (que se basa en el uso de selectores descendientes):

• Significa que tu estilo depende del contexto.
• Requiere una conciencia de la cascada. El código en un lugar puede afectar el código en otro lugar. En un equipo pequeño esto es algo bueno.
• Puede sufrir problemas de especificidad que pueden ser difíciles de depurar para un desarrollador novato.
• Es significativamente más apretado.

La tercera vía: componentes reales.

Si está utilizando algo como React, Angular 2 o cualquiera de las otras palabras de marco modernas de front-end, tiene otra solución. Puede usar herramientas para imponer la encapsulación.

Este ejemplo usa React y StyledJSX, pero hay muchas opciones. Aquí hay un widget:

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

A continuación, utilizaría el nuevo widget de esta manera:

<Widget />

Todos los estilos declarados en el widget se encapsularían y no se aplicarían a elementos fuera del componente. Somos libres de diseñar simplemente el divy el adirectamente sin preocuparnos por diseñar accidentalmente cualquier otra cosa en la página.

Ningún enfoque es perfecto. En mi humilde opinión, debemos obtener las mejores partes de cada una de las metodologías (BEM, SMACSS, OOCSS, DRY). Use SMACSS para organizar la estructura de su carpeta en su CSS, especialmente para definir el desglose del nivel lógico de todo el CSS. SECO para crear su biblioteca de utilidades o puede ser una biblioteca modificadora común que se utilizará a veces junto con clases basadas en BEM. OOCSS para componentes. Y BEM para componentes pequeños o subcomponentes. Ahí puedes distribuir la complejidad y obtener libertad para trabajar dentro de un gran equipo.

Cualquier cosa que se use sin comprender su esencia resultará en algo malo.

Si bien BEM es un buen enfoque para equipos más grandes, también tiene algunas desventajas. 1.A veces resulta en nombres muy largos en una estructura HTML grande. Tamaño de archivo CSS grande resultante. 2. Para anidar htmls que tiene más de 2-3 niveles, se convierte en un dolor de cabeza definir nombres.

La resolución de conflictos se puede gestionar fácilmente si pensamos en la estructura de componentes junto con un conjunto muy básico de estilo base. Es más una herencia de dos niveles solamente. Cada elemento dentro de un componente tendría una regla de estilo global o específica para ese componente. Esta es una de las opciones más fáciles.