Qu'est-ce qui rend BEM meilleur que l'utilisation d'un langage de feuille de style emboîtable comme LESS?

Un de mes collègues pousse fortement la méthode BEM ( Block Element Modifier ) pour le CSS dans un projet qu'il dirige, et je ne peux tout simplement pas comprendre ce qui le rend meilleur que le moins CSS que nous écrivons depuis des années.

Il réclame "des performances plus élevées", mais je ne peux pas imaginer comment les performances pourraient même avoir de l'importance pour les types d'applications Web que nous écrivons dans cette boutique de codes. Nous ne faisons pas Twitter ou Facebook, ici. Je serais très surpris si nos applications les plus utilisées ont plus de 10000 visites par mois , et la plupart sont bien en dessous de 1000.

Il revendique la «lisibilité» et la «réutilisation», mais MOINS fait déjà beaucoup mieux à mon avis. Et je pense que BEM gâche si mal le balisage avec des dizaines de caractères supplémentaires dédiés à ces noms de classe super longs qu'il réduit radicalement la lisibilité.

Il affirme que "le CSS imbriqué est un anti-modèle". Que signifie « anti-modèle » , même moyenne , et pourquoi est - imbriqué mauvaise CSS?

Il affirme que "tout le monde s'oriente vers l'utilisation du BEM, nous devrions donc le faire aussi". Mon compteur est "Si tout le monde sautait d'un pont, suivriez-vous?" Mais il est toujours totalement catégorique à ce sujet.

Quelqu'un pourrait-il expliquer en détail ce qui rend BEM meilleur que LESS? Mon collègue ne parvient pas à me convaincre complètement, mais je ne sais pas si j'ai d'autre choix que de suivre. Je préférerais vraiment pouvoir apprécier le BEM plutôt que de l'accepter à contrecœur.

Un de mes collègues pousse fortement la méthode BEM (Block Element Modifier) ​​pour le CSS dans un projet qu'il dirige, et je ne peux tout simplement pas comprendre ce qui le rend meilleur que le moins CSS que nous écrivons depuis des années.

BEM est une méthodologie CSS. D'autres comprennent OOCSS et SMACSS. Ces méthodologies sont utilisées pour écrire du code modulaire, extensible et réutilisable qui fonctionne bien à l'échelle.

LESS est un préprocesseur CSS. D'autres incluent Sass et Stylus. Ces préprocesseurs sont utilisés pour convertir leurs sources respectives en CSS étendu.

BEM et LESS ne sont pas comparables comme étant «meilleurs» l'un par rapport à l'autre, ce sont des outils qui ont des objectifs différents. Vous ne diriez pas qu'un tournevis est meilleur qu'un marteau, sauf si l'on considère l'utilité pour résoudre un problème spécifique.

Il réclame "des performances supérieures" ...

Les performances devraient être mesurées entre un style CSS classique de:

.widget .header

et le style BEM de:

.widget__header

mais d'une manière générale, les performances du sélecteur CSS ne sont pas un goulot d'étranglement et n'ont pas besoin d'être optimisées.

La «performance» de BEM concerne généralement le code d'écriture des performances d'un développeur. Si la méthodologie BEM est utilisée de manière cohérente et correcte, il est facile pour des groupes de développeurs de créer simultanément des modules distincts sans conflits de style.

Il réclame "lisibilité" et "réutilisation" ...

Je ne sais pas si je dirais à un nouveau développeur que BEM est plus lisible. Je peux dire qu'il fournit des directives bien définies quant à la signification et à la structure des classes.

Voir une classe comme

.foo--bar__baz

Me dit qu'il y a un foobloc qui est en l' barétat et contient un bazélément.

Je dirais absolument que le BEM est plus réutilisable qu'un modèle classique.

Si deux développeurs créent des blocs ( fooet bar) et que ces deux blocs ont des en-têtes, ils peuvent réutiliser en toute sécurité leurs blocs dans différents contextes sans se soucier d'une collision de noms.

En effet, dans un contexte classique, .foo .headinget .bar .headingserait en conflit, et d' introduire un conflit de spécificité qui doivent être résolus, peut - être au cas par cas.

Dans un site BEM, les classes seraient .foo__headinget .bar__heading, ce qui ne serait jamais en conflit.

Il affirme que "le CSS imbriqué est un anti-modèle". Que signifie "anti-pattern", et pourquoi le CSS imbriqué est-il mauvais?

Un "anti-modèle" est un modèle de codage plus facile à apprendre et à utiliser pour les développeurs inexpérimentés qu'une alternative plus appropriée.

En ce qui concerne les raisons pour lesquelles le CSS imbriqué est mauvais: l'imbrication augmente la spécificité d'un sélecteur. Plus la spécificité est élevée, plus il faut d'effort pour passer outre. Les développeurs inexpérimentés craignent souvent que leur CSS puisse affecter plusieurs pages, ils utilisent donc des sélecteurs comme:

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

Lorsqu'un développeur expérimenté craint que son CSS n'affecte pas plusieurs pages, il utilise donc des sélecteurs comme:

.more

Il affirme que "tout le monde s'oriente vers l'utilisation du BEM, nous devrions donc le faire aussi." ...

C'est une erreur de marche , alors ignorez cela comme un mauvais argument. Ne tombez pas dans le piège de l' erreur fallacieuse , car un mauvais argument en faveur du BEM n'est pas une raison de croire que le BEM ne peut pas être bon.

Quelqu'un pourrait-il expliquer en détail ce qui rend BEM meilleur que LESS?

J'ai couvert cela auparavant, BEM & LESS ne sont pas comparables. Pommes et oranges, etc.

Mon collègue ne parvient pas à me convaincre complètement, mais je ne sais pas si j'ai d'autre choix que de suivre.

Je recommande de jeter un œil à OOCSS, SMACSS et BEM, et de peser le pour et le contre de chaque méthodologie ... en équipe . J'utilise BEM parce que j'aime sa rigueur de format, et ne me dérange pas les sélecteurs laids, mais je ne peux pas vous dire ce qui est bon pour vous ou pour votre équipe. Ne laissez pas un franc-parler diriger le spectacle. Si vous n'êtes pas à l'aise avec BEM, sachez qu'il existe d'autres alternatives qui pourraient être plus faciles à prendre en charge par votre équipe. Vous devrez peut-être défendre votre position auprès de votre collègue, mais à long terme, cela aura probablement un effet positif sur le résultat de vos projets.

Je préférerais vraiment pouvoir apprécier le BEM plutôt que de l'accepter à contrecœur.

J'ai écrit une réponse sur StackOverflow qui décrit le fonctionnement de BEM . La chose importante à comprendre est que vos sélecteurs idéaux devraient avoir une spécificité de 0-0-1-0sorte qu'ils soient faciles à remplacer et à étendre.

Choisir d'utiliser BEM ne signifie pas que vous devez abandonner MOINS! Vous pouvez toujours utiliser des variables, vous pouvez toujours utiliser @imports et vous pouvez certainement continuer à utiliser l'imbrication. La différence est que vous voulez que la sortie rendue devienne une seule classe, plutôt qu'une chaîne descendante.

Où vous auriez pu avoir

.widget {
    .heading {
        ...
    }
}

Avec BEM, vous pouvez utiliser:

.widget {
    &__heading {
        ...
    }
}

De plus, étant donné que BEM tourne autour de blocs individuels, vous pouvez facilement séparer le code en fichiers séparés. widget.lesscontiendrait des styles pour le .widgetbloc, tandis component.lessque contiendrait des styles pour le .componentbloc. Cela facilite beaucoup la recherche de la source pour n'importe quelle classe particulière, bien que vous souhaitiez peut-être toujours utiliser des cartes sources.

Modifier 2017

Si vous lisez ceci en 2017, les polyfills DOM DOM et shadow DOM, ainsi que les composants résolvent tous ces problèmes, tout en gardant votre code petit, serré et modulaire. N'utilisez pas BEM sur un projet greenfield IMO.

Au lieu de BEM, nous avons des outils comme ViewEncapsulation, Polymer, StyledJSX, SASS Modules, Styled Components, etc.

Pensez à utiliser BEM si vous ne disposez pas d'une architecture orientée composants; si vous avez un code hérité à prendre en charge; ou si vous êtes juste prêt à tout faire manuellement sans outillage.

BEM rend votre style indépendant de votre imbrication DOM. Pour ce faire, il donne à chaque élément que vous souhaitez définir un attribut de classe big-ass susceptible d'être unique sur votre page. La plupart du style se fait ensuite sur les classes.

Cela rend votre code plus modulaire, car l'imbrication n'est plus prise en compte, au détriment de beaucoup de verbosité.

Sans BEM

Sans BEM, nous pourrions écrire ceci:

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

Le style CSS standard pourrait ressembler à ceci:

.widget {
  border: 1px solid red;
}

.widget a {
  color: green;
}

La même chose avec SASS ressemblerait à ceci:

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

Si vous êtes une petite équipe où tout le monde peut coder CSS à un niveau élevé et que le projet est suffisamment petit pour que vous puissiez en avoir pleinement connaissance, c'est une bonne solution raisonnable.

Avec BEM

Cependant, si votre code devient plus grand et que vous avez une grande équipe de compétences mixtes, cela pourrait ne pas être une solution aussi simple. Et si vous voulez des ancres vertes dans un autre widget par exemple. Nous rendons donc l'ancre modulaire et éliminons les sélecteurs descendants.

Maintenant, notre HTML est beaucoup plus verbeux:

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

Notre CSS n'a pas de sélecteurs descendants:

.widget {
  border: 1px solid red;
}

.widget__anchor {
  color: green;
}

Mais nous pouvons maintenant le faire:

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

Le widget__anchor est modulaire. Il est peu probable qu'une autre définition de .widget__anchor existe sur la page.

compromis:

BEM:

• Vous donne un code plus modulaire. Vous pouvez prendre n'importe quelle pièce isolément.
• Permet à n'importe qui d'écrire du CSS. Vous n'avez pas besoin de connaître le style principal et les remplacements personnalisés. Dans une grande équipe, c'est sympa.
• Supprime tous les problèmes de spécificité.
• Est beaucoup plus verbeux.

CSS standard (qui repose sur l'utilisation de sélecteurs descendants):

• Signifie que votre style dépend du contexte.
• Nécessite une prise de conscience de la cascade. Le code en une fois peut affecter le code ailleurs. Dans une petite équipe, c'est une bonne chose.
• Peut souffrir de problèmes de spécificité qui peuvent être difficiles à déboguer pour un développeur débutant.
• Est nettement plus serré.

La troisième voie - Real Components.

Si vous utilisez quelque chose comme React, Angular 2 ou l'un des autres mots de passe frontaux modernes, vous avez une autre solution. Vous pouvez utiliser des outils pour appliquer l'encapsulation.

Cet exemple utilise React et StyledJSX, mais il existe de nombreuses options. Voici un widget:

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

Vous utiliseriez alors le nouveau widget comme ceci:

<Widget />

Tous les styles déclarés dans le widget seraient encapsulés et ne s'appliqueraient pas aux éléments en dehors du composant. Nous sommes libres de simplement styliser le divet le adirectement sans nous soucier de styliser accidentellement autre chose sur la page.

Aucune approche n'est parfaite. À mon humble avis, nous devrions obtenir les meilleures parties de chacune des méthodologies (BEM, SMACSS, OOCSS, DRY). Utilisez SMACSS pour organiser la structure de vos dossiers dans votre CSS, spécialement pour définir la répartition du niveau logique de l'ensemble du CSS. DRY to pour créer votre bibliothèque d'utilitaires ou peut être une bibliothèque de modificateurs commune à utiliser parfois en conjonction avec des classes basées sur BEM. OOCSS pour les composants. Et BEM pour les petits composants ou sous-composants. Là, vous pouvez distribuer la complexité et obtenir la liberté de travailler au sein d'une grande équipe.

Tout ce qui est utilisé sans en comprendre l'essence en résultera mauvais.

Bien que BEM soit une bonne approche pour les grandes équipes, il présente également des inconvénients. Il en résulte parfois des noms très longs dans une grande structure HTML. Résultat: grande taille de fichier CSS. 2. Pour l'imbrication de fichiers HTML de plus de 2 à 3 niveaux, il devient difficile de définir des noms.

La résolution des conflits peut être facilement gérée si nous pensons à la structure des composants avec un ensemble très basique de style de base. Il s'agit plutôt d'un héritage à deux niveaux uniquement. Chaque élément à l'intérieur d'un composant aurait une règle de style globale ou spécifique à ce composant. C'est l'une des options les plus faciles.