Что делает BEM лучше, чем использование такого языка таблиц стилей, как LESS?

Мой коллега активно продвигает метод BEM ( Block Element Modifier ) для CSS в проекте, который он разрабатывает, и я просто не могу понять, что делает его лучше, чем LESS CSS, который мы писали годами.

Он заявляет о «более высокой производительности», но я не представляю, как производительность может иметь значение для тех веб-приложений, которые мы пишем в этом магазине. Мы не делаем Twitter или Facebook, здесь. Я был бы очень удивлен, если бы наши приложения с наибольшим использованием имели более 10000 посещений в месяц , а большинство из них - менее 1000.

Он утверждает, что «читабельность» и «повторное использование», но МЕНЬШЕ уже делает это намного лучше , по моему мнению. И я чувствую, что БЭМ так плохо справляется с разметкой с помощью десятков дополнительных символов, предназначенных для этих сверхдлинных имен классов, что радикально снижает читабельность.

Он утверждает, что «вложенный CSS - это анти-шаблон». Что означает «анти-модель» даже средний , и почему вложенная CSS плохо?

Он утверждает, что «все движутся к использованию БЭМ, поэтому мы тоже должны». Мой счетчик: «Если бы все прыгали с моста, вы бы пошли?» Но он все еще непреклонен в этом.

Может кто-нибудь объяснить, что делает БЭМ лучше, чем МЕНЬШЕ? Мой коллега совершенно не может убедить меня, но я не знаю, есть ли у меня выбор, кроме как следовать. Я бы скорее оценил БЭМ, чем неохотно принял это.

Мой коллега активно продвигает метод BEM (Block Element Modifier) ​​для CSS в проекте, который он разрабатывает, и я просто не могу понять, что делает его лучше, чем LESS CSS, который мы писали годами.

БЭМ - это методология CSS. Другие включают OOCSS и SMACSS. Эти методологии используются для написания модульного, расширяемого, многократно используемого кода, который хорошо работает в масштабе.

LESS - это препроцессор CSS. Другие включают Sass и Stylus. Эти препроцессоры используются для преобразования их соответствующих источников в расширенный CSS.

БЭМ и МЕНЬШЕ не сопоставимы, поскольку они «лучше» друг друга, они являются инструментами, которые служат различным целям. Вы бы не сказали, что отвертка лучше, чем молоток, за исключением случаев, когда вы рассматриваете утилиту для решения конкретной проблемы.

Он утверждает, что "более высокая производительность" ...

Производительность должна измеряться между классическим стилем CSS:

.widget .header

и стиль БЭМ:

.widget__header

но, вообще говоря, производительность CSS-селектора не является узким местом и не нуждается в оптимизации.

БЭМ "производительность" обычно относится к написанию кода производительности разработчика. Если методология БЭМ используется последовательно и правильно, группам разработчиков легко одновременно создавать отдельные модули без стилевых коллизий.

Он утверждает, что «читаемость» и «повторное использование» ...

Я не знаю, что скажу новому разработчику, что БЭМ более читабелен. Я могу сказать, что он предоставляет некоторые четко определенные рекомендации относительно значения и структуры классов.

Видя класс как

.foo--bar__baz

Сообщает мне, что есть fooблок, который находится в barсостоянии, и содержитbaz элемент.

Я бы сказал, что БЭМ более пригоден для повторного использования, чем классическая модель.

Если два разработчика создают блоки ( fooиbar ), и оба этих блока имеют заголовки, они могут безопасно повторно использовать свои блоки в разных контекстах, не беспокоясь о конфликте имен.

Это потому, что в классическом контексте .foo .headingи.bar .heading будет конфликтовать, и вводить конфликт специфики, который необходимо будет решить, возможно, на индивидуальной основе.

На сайте БЭМ классы были бы .foo__headingи .bar__heading, что никогда не будет конфликтовать.

Он утверждает, что «вложенный CSS - это анти-шаблон». Что вообще означает «анти-паттерн» и почему плохо вложенный CSS?

«Анти-паттерн» - это паттерн кодирования, который неопытным разработчикам легче изучить и использовать, чем более подходящую альтернативу.

Что касается того, почему вложенный CSS - это плохо: вложение увеличивает специфичность селектора. Чем выше специфичность, тем больше усилий требуется для переопределения. Неопытные разработчики часто беспокоятся, что их CSS может повлиять на несколько страниц, поэтому они используют селекторы, такие как:

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

Когда опытный разработчик будет беспокоиться о том, что его CSS может не повлиять на несколько страниц, он использует такие селекторы, как:

.more

Он утверждает, что «все движутся к использованию БЭМ, поэтому мы тоже должны».

Это заблуждение , так что игнорируйте это как плохой аргумент. Не попадайтесь в ловушку ошибочной ошибки , потому что плохой аргумент в поддержку БЭМ не является основанием полагать, что БЭМ не может быть хорошим.

Может кто-нибудь объяснить, что делает БЭМ лучше, чем МЕНЬШЕ?

Я рассмотрел это раньше, BEM & LESS не сопоставимы. Яблоки и апельсины и др.

Мой коллега совершенно не может убедить меня, но я не знаю, есть ли у меня выбор, кроме как следовать.

Я рекомендую взглянуть на OOCSS, SMACSS и BEM и взвесить все за и против каждой методологии ... как команда . Я использую БЭМ, потому что мне нравится его строгость в формате, и я не против уродливых селекторов, но я не могу сказать вам, что подходит вам или вашей команде. Не позволяйте одному откровенному человеку управлять шоу. Если вам не нравится BEM, помните, что есть и другие альтернативы, которые вашей команде будет проще поддержать. Возможно, вам придется защищать свою позицию с коллегой, но в долгосрочной перспективе это, вероятно, окажет положительное влияние на результаты ваших проектов.

Я бы скорее оценил БЭМ, чем неохотно принял это.

Я написал ответ на StackOverflow, который описывает, как работает БЭМ . Важно понимать, что ваши идеальные селекторы должны иметь специфику0-0-1-0 чтобы их было легко переопределять и расширять.

Выбор использования БЭМ не означает, что вам нужно отказаться от МЕНЬШЕ! Вы все еще можете использовать переменные, вы все еще можете использовать @imports, и вы, конечно, можете продолжать использовать вложение. Разница в том, что вы хотите, чтобы отображаемый вывод стал единым классом, а не цепочкой-потомком.

Где вы могли иметь

.widget {
    .heading {
        ...
    }
}

С BEM вы можете использовать:

.widget {
    &__heading {
        ...
    }
}

Кроме того, поскольку БЭМ вращается вокруг отдельных блоков, вы можете легко разделить код на отдельные файлы. widget.lessбудет содержать стили для .widgetблока, в то время как component.lessбудет содержать стили для .componentблока. Это значительно упрощает поиск источника для любого конкретного класса, хотя вы все еще можете использовать исходные карты.

Редактировать 2017

Если вы читаете это в 2017 году, теневые DOM и теневые DOM полифилы, а также компоненты решают все эти проблемы, сохраняя при этом ваш код небольшим, компактным и модульным. Не используйте БЭМ в новом проекте IMO.

Вместо BEM у нас есть такие инструменты, как ViewEncapsulation, Polymer, StyledJSX, SASS, Styled Components и т. Д.

Рассмотрите возможность использования BEM, если у вас нет компонентно-ориентированной архитектуры; если у вас есть устаревший код для поддержки; или если вы просто мертвы на все вручную, без инструментов.

БЭМ делает ваш стиль независимым от вложенности DOM. Это достигается путем предоставления каждому элементу, который вы можете захотеть стилизовать атрибут класса с большой задницей, который, вероятно, будет уникальным на вашей странице. Большая часть стиля тогда сделана на классах.

Это делает ваш код более модульным, потому что вложение больше не учитывается, за счет значительной детализации.

Без БЭМ

Без БЭМ мы могли бы написать это:

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

Стандартный стиль CSS может выглядеть следующим образом:

.widget {
  border: 1px solid red;
}

.widget a {
  color: green;
}

То же самое с SASS будет выглядеть так:

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

Если вы небольшая команда, где каждый может кодировать CSS в соответствии с высокими стандартами, а проект достаточно мал, чтобы вы могли полностью его осознать, это хорошее и разумное решение.

С БЭМ

Однако, если ваш код становится больше, и у вас большая команда со смешанными способностями, это может быть не таким простым решением. Что делать, если вы хотите зеленые якоря в другом виджете, например. Таким образом, мы сделаем привязку модульной и исключим потомки селекторов.

Теперь наш HTML гораздо более многословен:

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

Наш CSS не имеет потомков селекторов:

.widget {
  border: 1px solid red;
}

.widget__anchor {
  color: green;
}

Но теперь мы можем сделать это:

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

Виджет __anchor является модульным. Маловероятно, что на странице будет другое определение .widget__anchor.

компромиссные:

BEM:

• Дает вам более модульный код. Вы можете взять любой кусок в изоляции.
• Позволяет любому писать CSS. Вам не нужно знать о мастер-стилях и пользовательских переопределениях. В большой команде это приятно.
• Удаляет любые проблемы специфичности.
• Это значительно более многословно.

Стандартный CSS (который основан на использовании селекторов-потомков):

• Значит, ваш стиль зависит от контекста.
• Требуется осознание каскада. Код в одном месте может повлиять на код в другом месте. В небольшой команде это хорошо.
• Может страдать от проблем специфичности, которые могут быть трудны для отладки начинающим разработчиком.
• Это значительно теснее.

Третий путь - реальные компоненты.

Если вы используете что-то вроде React, Angular 2 или любого другого из современных интерфейсных фреймвордов, у вас есть другое решение. Вы можете использовать инструменты для обеспечения инкапсуляции.

В этом примере используются React и StyledJSX, но есть много вариантов. Вот виджет:

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

Затем вы бы использовали новый виджет следующим образом:

<Widget />

Все стили, объявленные в виджете, будут инкапсулированы и не будут применяться к элементам вне компонента. Мы можем просто стилизовать divи aнапрямую, не беспокоясь о том, чтобы случайно стилизовать что-либо еще на странице.

Ни один подход не идеален. ИМХО, мы должны получить лучшие части каждой из методологий (BEM, SMACSS, OOCSS, DRY). Используйте SMACSS для организации структуры папок в вашем CSS, особенно для определения логического уровня всего CSS. СУХОЙ для создания вашей служебной библиотеки или может быть общей библиотекой модификаторов, которая иногда используется в сочетании с классами, основанными на БЭМ. OOCSS для компонентов. И БЭМ для небольших компонентов или субкомпонентов. Там вы можете распределить сложность и получить свободу для работы в большой команде.

Все, что используется, не понимая сути этого, будет плохо.

Хотя БЭМ является хорошим подходом для больших команд, у него есть и недостатки. 1. Иногда это приводит к очень длинным именам в большой структуре HTML. В результате большой размер файла CSS. 2. Для вложения htmls, состоящих более чем из 2-3 уровней, определение имен становится головной болью.

Разрешение конфликтов может легко управляться, если мы думаем о структуре компонентов вместе с очень простым набором базовых стилей. Это скорее только двухуровневое наследование. Каждый элемент внутри компонента будет иметь либо глобальное правило стиля, либо определенное для этого компонента. Это один из самых простых вариантов.