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

27

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.

coredumperror
la source
1
BEM et LESS ont des objectifs différents. J'utilise à la fois BEM et LESS.
zzzzBov
4
Notez que BEM ne concerne pas principalement CSS - il s'agit d'identifier les modèles récurrents encapsulés dans votre conception et de rassembler tout ce dont vous avez besoin pour ce bloc (comportement, modèle, styles) en un seul endroit central. Même s'il est limité au CSS, BEM est toujours un excellent moyen d'organiser vos styles et d'éviter de manière fiable les conflits de noms. Tout cela est totalement indépendant des préprocesseurs tels que LESS ou SASS, qui sont des langages de style plus productifs que le CSS simple car ils offrent des macros et des variables et une notation abrégée et toutes sortes de fonctionnalités intéressantes. MOINS = gagner, BEM = gagner, mais MOINS × BEM = gagner²!
amon

Réponses:

29

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.

zzzzBov
la source
4
@CoreDumpError, le problème est lorsque vous commencez à imbriquer des modules dans des modules. "chaque développeur peut simplement imbriquer le code de son widget spécifique un niveau plus en profondeur" n'est pas tout à fait correct, chaque développeur doit imbriquer le code de son widget spécifique de plus en plus profondément sinon la dénomination des collisions en cascade de manière généralement non intentionnelle. La seule façon d'éviter les conflits de noms est d'utiliser une sorte d'espacement de noms, et BEM offre un moyen facile de classer les classes d'espaces de manière cohérente.
zzzzBov
3
@CoreDumpError, Considérez cet exemple . Un auteur qui écrit sans BEM doit consacrer des efforts supplémentaires à vérifier chaque combinaison de chaque module qui pourrait être ajoutée dans son module. Un auteur utilisant BEM ne le fait pas.
zzzzBov
1
@CoreDumpError, cela pourrait certainement l'être. Je trouve que BEM est facile à former de nouveaux développeurs et facilite la révision du code, mais SMACSS et OOCSS sont de bonnes alternatives. Je recommande fortement d'étudier ces options comme alternative. Je dirai que j'utilise BEM pour mon propre développement afin de ne pas entrer en conflit avec moi-même, surtout avec le futur moi, qui est stupide et oublie les choses.
zzzzBov
1
Je trouve que BEM est excellent sur tout projet qui implique toute sorte de complexité est CSS. Vous pouvez avoir un site qui se trouve sur WordPress et n'utilise que Javascript pour déclencher des choses sur défilement, mais est toujours aussi complexe qu'une application Web dans le CSS. Il est important de ne pas tomber dans le piège de penser `` mon site n'est pas complexe '' simplement parce qu'il fait la plupart de ses éléments uniquement dans le domaine visuel (comme le font de nombreux sites de marketing)
Toni Leigh
1
@CoreDumpError la plupart de mes projets précédents ont été des efforts en solo, et je suis arrivé à une grande partie de BEM sur ma propre re: spécificité et sélecteurs uniques. La maintenance d'une base de code est un énorme problème qui devient extrêmement clair avec BEM. Le code est la maintenance. Construire des choses est facile. Il est difficile de conserver des modèles parfaits, surtout après quelques mois d'absence de la base de code. Les problèmes de spécificité s'aggravent avec le temps. Les avantages s'appliquent à toute taille d'équipe IMO!
Yuji Tomita
8

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.

superluminaire
la source
1
Avantages et inconvénients sans favoriser aucun côté, j'aime ça.
Adrian Moisa
Je pense qu'il y a quelque chose de vraiment triste à dire "écrivez votre code comme ça pour que les gens qui ne comprennent pas la cascade puissent le comprendre". C'est comme dire "J'écris mon code sans tableau parce qu'un des membres juniors de l'équipe ne comprend pas comment fonctionnent les tableaux". Personnellement, je préfère la méthode la plus succincte qui favorise le côté en cascade naturel des feuilles de style en cascade.
Matt Fletcher
@MattFletcher - Je pense que c'est une question de taille de projet. La cascade est intrinsèquement mondiale. Vous définissez des valeurs, puis remplacez et redéfinissez vers le bas dans l'arborescence. Si vous avez un projet plus petit avec une visibilité totale, c'est bien, mais sur un projet plus grand, il devient fragile. Les gens ont peur de changer les choses parce qu'un changement plus haut dans la cascade casse des choses aléatoires dans d'autres endroits. L'encapsulation des composants est en fait très agréable sur les grands projets. Tout fonctionne.
Superluminaire
2

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.

user224551
la source
Très bon argument. Les développeurs doivent être capables de penser par eux-mêmes et d'analyser l'ampleur du problème. Le fait de suivre aveuglément des méthodologies vous mène toujours à des ennuis. J'ai des collègues qui ne considèrent pas du tout les effets de leurs changements sur la page et quelle que soit la méthodologie que nous avons, les choses vont au sud dans le temps. Je m'efforce de rehausser le niveau de sensibilisation CSS dans l'équipe. SASS imbriqué avec des styles locaux et des styles globaux est suffisant pour garder le projet propre et facile à lire.
Adrian Moisa