В чем суть БЭМ от Яндекса?

Question

[littleguga]

По смыслу же это - jquery/gulp/jade - от яндекса?
Я читаю документацию, но никак не могу понять, в чем преимущество использования данной технологии. Какой с этого профит?

Answer 1

[Денис Инешин]

По сути все сборщики там это всё вторично. Главное сам принцип именования и использования классов в HTML и CSS. Этот подход позволяет сохранять единообразный подход к разработке даже в самой большой команде. Кроме того позволяет обмениваться модулями (html+css+js) между командами. Например одна команда написала скажем sidebar. Другая команда теперь может легко и просто вставить его в свой проект, не беспокоясь о конфликте CSS стилей или имен классов.

Comments

[littleguga]

А чем подход element-children-deeperchild Плох?

<div class="element">
    <div class="element-children">
         <div class="element-children-title">
                  Заголовок
         </div>
         <div class="element-children-content">
                  <div class="element-children-content-img">
                      картинка
                  </div>
                  <div class="element-children-content-text">
                      текст
                  </div>
         </div>
     </div>
</div>

Или можете подсказать другие подходы к именованию и использованию классов? Вы используете БЭМ?

[Сергей Протько]

littleguga: он плохо разделяет по смыслу стили, но в целом добивается примерно тех же целей. Вопрос именования классов - дело второстепенное как по мне.

[littleguga]

Сергей Протько: а что первостепенное?

[Сергей Протько]

littleguga: разделение стилей по назначению, изоляция стилей, контроль.

[Сергей Протько]

littleguga: ну и да, с внедрением web-компонентов должно быть уже проще с этим.

Answer 2

[Сергей Протько]

По смыслу же это - jquery/gulp/jade - от яндекса?

это bem-tools, сама методология BEM чуть отличается все же.

блок - базовые стили маленького блока, какой-то конкретной составляющей UI
элемент - стили отвечающие за позиционирование вложенных блоков или просто элементов
модификаторы - стили, меняющие оформление блока или его элементов.

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

https://www.youtube.com/watch?v=RM55tkWfHDc - рекомендую к просмотру доклад Вадима Макеева на эту тему. Думаю так будет проще.

Comments

[littleguga]

А какой методологией именования классов Вы пользуетесь?

[Сергей Протько]

littleguga: я не пользуюсь методологиями "именования класов". Если для вас BEM это именно "именование классов" то печаль беда. Это разделение стилей по назначению, дробление всего на блоки, отказ от каскадирования (или минимизация скорее) с целью получить более управляемые стили. Причем BEM это крайнее проявление этих идей.

Я для стилей пользуюсь принципами SOLID, можно это пожалуй так назвать. А для именований когда как, но в последнее время все чаще предпочитаю вариант bem или что-то схожее.

[littleguga]

Сергей Протько: >Если для вас BEM это именно "именование классов" то печаль беда.
Что для меня БЭМ - можно увидеть в вопросе, сейчас буду дальше изучать/понимать его. Про именование - я просто спросил.

Answer 3

[un1t]

Нужно различать технологии БЭМ и стандарт кодирования БЭМ. Правда стандарт кодирования они почему-то называют методологией, вероятно, чтобы придать больше важности и избежать конкретики, потому что стандарт кодирования это вещь простая и конкретная, а методология очень абстрактная.
Вобщем идея именования классов для выделения связанной логики в блоки довольно хороша и удобна для разработки и поддержки. А вот с технологиями тут все довольно печально, лучше испольовать общепринятые gulp/jquery/angular и прочее, по ним и информации больше и плагинов и комьюнити и работают они лучше.

Например одна команда написала скажем sidebar. Другая команда теперь может легко и просто вставить его в свой проект, не беспокоясь о конфликте CSS стилей или имен классов.

В теории это наверно так, по крайней мере об этом все говорят. Конфликтов стилей действительно не будет, это плюс. Но переиспользовать получается только уж совсем элементарные блоки типа логотипа и иногда попапа. А вот какой-нибудь слайдер уже не получается, хоть ты тресни. У одного проекта одни требования к слайдеру, у дргого другие. Решения получаются слишком часные, а если делать общее решение на все случаи жизни, то оно получиться очень громоздким и слишком абстрактным для того чтобы его можно было использовать. Если бы заявленное было правдой, то после выхода компонентов в стиле островов у Яндекса бы все сайты почти автоматически переоформились под новый стиль и все. А по факту это переписывание фронтэнда заново.