И так далее. В среднем блогмониторинг приносит пару новых статей про БЭМ в день.
Ну а из местных костылятелей табличного говнокода, кроме Яндекса могу предложить к изучению опыт
* mail.ru (https://habrahabr.ru/company/mailru/blog/250783/ + https://habrahabr.ru/company/mailru/blog/142193/ + https://habrahabr.ru/company/mailru/blog/263221/)
* http://www.rambler.ru/
* Альфа-банка (https://github.com/alfa-bank-dev/ui)
* http://learn.javascript.ru/
Ну и так далее.
PS: вы в предыдущем комментарии упомянули годные практики, которым БЭМ противоречит. Поделитесь?
> Читайте внимательно: здравому смыслу небольших проектов.
Так ведь это… я и для небольших проектов никакого вреда от применения БЭМа не вижу. Он есть? :)
Что до тулсета, то опять же, мы все время твердим, что БЭМ — штука модульная, можно брать по частям.
> не путать БЭМ с вёрсткой по БЭМ
Звучит примерно как не путать чаепитие с чайной церемонией ;)
Предполагается, что есть такие тонкие ценители, которые могут определить ту грань, когда вот только что была верстка по БЭМ и тут опа-па и стал БЭМ?
Я, конечно, догадываюсь, что под этим разделением понимают использование JS фреймворка, оперирующего блоками, декларативного шаблонизатора, опять же работающего с блоками, и сборки, понимающей, как собрать нужные блоки с файловой системы в общий бандл. Но вот, скажем, стали мы собирать БЭМ-проекты на gulp (https://ru.bem.info/forum/782/) или, допустим, Webpack (https://ru.bem.info/forum/774/) — это теперь не БЭМ, а верстка по БЭМ? :)
> для новичка поезд с легким освоением деталей уже ушел
На самом деле у нас движение в противоположную сторону. Мы планомерно упрощаем документацию (да и инструментарий), выпиливаем сложное, добавляем простые примеры и пытаемся учитывать конструктивную критику и повторяющиеся вопросы на форуме.
Сейчас методологический раздел https://ru.bem.info/method/ содержит те самые 5 страниц + историю появления, так что поводов для паники быть не должно. Но мое предложение в силе — если есть конкретные моменты, которые звучат непонятно — буду рад про них узнать и улучшить.
> Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM»
Вот, скажем, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ англоязычный пост за январь 2013, где Гарри Робертс ссылается на Николаса Галлахера и делится своими соображениями про БЭМ.
> Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
Смотря что вы подразумеваете под «стилем написания CSS». В документации на bem.info приводятся примеры разных вариантов нейминга, разных схем организации файловой структуры, примеры с вложенными селекторами, в общем, все то, про что вы в статье пишите. Однозначно мы, разве что, утверждаем, что селекторы на id не нужны никогда ;)
Идея БЭМ в плане организации JS кода в своей основе совпадает с идеей Web Components — разделение интерфейсы на компоненты/блоки так, чтобы все технологии этого компонента (CSS, JS, шаблоны, тесты, etc) были рядом и могли быть с легкостью переиспользованы на других проектах.
Если смотреть на частности, то Web Components достигает этого специальными требованиями к браузерному API, а текущие реализации БЭМ — тем фактом, что JS использует те же селекторы, что и CSS. Плюс, в зависимости от реализации, добавляются еще всякие хелперы про установку/снятие модификаторов, чтобы было удобно выражать состояние компонента (как state в Реакте, только используется с 2008 года), плюшки про подписку на событие изменения модфикаторов и прочие полезности. Но еще раз повторюсь, что это уже вопрос конкретного решения, которое вы будете использовать, методология же говорит лишь про расположение на файловой системе и то, что следует использовать общие селекторы на блоки/элементы, а состояние выражать через модификаторы.
Я боюсь, что мы по-разному понимаем термины. Что вы вкладываете в «структурированный по БЭМ»?
Если речь про структурирование на файловой системе, то очевидно, что класть JS можно по признаку того, что это JS в одну папку (либо делать в ней подпапки при желании). А можно, как рекомендует БЭМ-методология, класть JS, описывающий поведение блока, в папку с этим блоком.
При необходимости переиспользовать эти блоки в новом проекте не придется искать их ошметки в разных папках — все рядом.
Ну и рано или поздно вам понадобится написать юнит-тесты для этих блоков, какую-то документацию, картинки сложить — они тоже естественным образом попадут в эти папки и все останется стройно и логично.
Подробно про все это опять-таки есть на bem.info, со всеми возможными вариантами (пишу на случай, если кто-то опять захочет сказать, что в БЭМ строго и ни шагу в стороны — вариантов предостаточно): https://ru.bem.info/method/filesystem/
А если речь про написание собственно кода, то могу предложить вот такой пост на тему для начала https://ru.bem.info/forum/163/
Дальше можно смотреть в сторону https://github.com/hoho/jquery-bem
А если хочется по-настоящему серьезно подойти к вопросу, то https://ru.bem.info/technology/i-bem/
Вот ведь что странно: я согласен с основным тезисом автора, что БЭМ — это хорошо, а практически с каждой отдельной фразой — нет. Как так получилось-то? :)
Попробую аргументировать.
> BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом
Можно, пожалуйста, ссылки и цитаты с bem.info или какой-либо статьи/выступления от Яндекса, где рекомендации как-то противоречат здравому смыслу или как-то мешают на небольших проектах?
Мы тут некоторое время назад попросили у наших коллег из Поиска поискать в дампе всего интернета сайты, которые используют верстку по БЭМ и чиселка получилась о-о-очень нехилая.
Ну и я лично знаю немало студий и даже фрилансеров-одиночек, которые используют БЭМ и довольны.
> И да, то самое чувство, когда читаешь официальные доки по BEM.
Буду очень благодарен, если ткнете носом в непонятные моменты документации.
Если они и правда до сих пор имеют место быть (мы постоянно работаем над улучшением документации), то с вашей помощью сможем улучшить и новичкам станет легче жить.
> 2015: BEM
Например, вот Я.Субботник 2011 — https://events.yandex.ru/lib/talks/217/
А вот пост в клуб БЭМ за 2009: https://ru.bem.info/forum/-46/
Так что все началось сильно раньше Бутстрапа и примерно в тот момент, когда в интернетах стало модно верстать семантично и валидно ;)
> к другим методологиям в глазки не заглядывать, свой HTML руками не трогать, чужой CSS домой не приводить.
Покажите, где вы про это узнали? Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками (тем же Бутстрапом при желании и делюсь ссылками на решения, где БЭМ объединяют с Реактом, Ангуляром, you-name-it).
И даже HTML, грешным делом, бывает руками пишу, хотя и в самом деле есть способы поэффективнее ;)
> Развидеть двойное подчеркивание
Тут, пожалуй, сложно не согласиться, тем более что ровно про эту возможность подробно написано на bem.info в разде про нейминг: https://ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Там же приводится ссылка на инструмент, позволяющий писать вообще как угодно.
> Лаконичные модификаторы
На первый взгляд звучит неплохо, но есть проблема: https://ru.bem.info/faq/#Почему-в-БЭМ-не-рекомендуется-использовать-комбинированные-селекторы-для-создания-css-правил-к-модификатору
Если для вас экономия времени на набор нескольких символов перевешивает возникающие в результате проблемы — дело ваше. БЭМ не запрещает, но «не рекомендует». И плюс-минус ваши же примеры приводятся на bem.info ;)
> Каскадность
Строгие читатели отругали нас за использование слова «каскад» не по спеке. На самом деле это про вложенные селекторы.
Так вот, тут снова БЭМ не запрещает, а говорит, что использование «нежелательно», объясняет почему и тут же приводит примеры, когда это оправдано: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Впрочем, мы регулярно пытаемся в комментариях к статьям на Хабре рассказать, как все на самом деле (например, вот тут про это же пишет Харисов https://habrahabr.ru/post/151931/#comment_5165248), но люди упорно пишут новые статьи, где говорят то же самое, что и мы, но как будто это они только что придумали, а в Яндексе зачем-то едят кактус :)
Еще немного мифов я попытался развенчать в этом посте: https://ru.bem.info/forum/158/
Настоятельно рекомендую.
PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
1. БЭМ и инструменты — действительно разные вещи. «Если бы мне давали доллар каждый раз, когда я это повторяю...»
2. Мы написали о заморозке bem-tools летом 2014: https://ru.bem.info/forum/-659/
3. На текущий момент сборка с помощью bem-tools просто вызывает ENB под капотом.
4. На последнем хакатоне мы начали писать bem-tools 2.0 ground up (но в них по-прежнему будет использоваться ENB для сборки).
> Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
> И это совсем не обнадеживает.
Предлагаю посмотреть на происходящее чуть-чуть внимательнее. ENB — это ядро, оно просто запускает плагины.
А вот где лежат плагины: https://github.com/enb-bem/ — в организации 18 репозиториев и 19 участников, среди которых нет Марата. А в целом NPM находит 96 пакетов по запросу enb. Так что жизнь тут бьет ключом.
Справедливости ради, после того, как Марат написал ядро и базовые технологии ENB, потребовалось гораздо больше времени на то, чтобы с помощью ENB стало можно собирать все то многообразие проектов, которое собиралось на bem-tools. Эту работу подхватила команда инструментов и продолжает ее двигать. За время, пока над ней работает новая команда, сборка на ENB стала еще быстрее, заметная часть кода переехала из ядра или была переписана.
Но главное — это то, что сборка БЭМ-проектов возможна любым другим сборщиком.
Подробнее см. посты про сборку на gulp и webpack:
https://ru.bem.info/forum/782/
https://ru.bem.info/forum/774/
> Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-синтаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller
Историческая справка:
Мы начинали с XML-синтаксиса и перешли на JS.
React изначально предложили JSX, а потом добавили поддержку JS ;)
Очевидно, что вместо BEMJSON можно использовать любой синтаксис, позволяющий описать дерево. Например, вот так выглядит поддержка yaml: https://github.com/tadatuta/enb-yaml-to-bemjson/blob/master/techs/yaml-to-bemjson.js (20 строк кода), а вот так https://github.com/tadatuta/enb-html-to-bemjson/blob/master/techs/html-to-bemjson.js — можно писать прямо на HTML.
Так что это вопрос исключительно предпочтений.
Про конкретные реализации Model/Controller совсем не понял. Тут БЭМ точно ничего не навязывает, есть примеры использования с Backbone (см. http://2013.404fest.ru/reports/backbone/), реализации для Angular (https://github.com/bem-contrib/ng-bem-components) и так далее.
Кстати, все тот же React дружит с БЭМ: https://github.com/search?utf8=✓&q=bem+react
Так что да, БЭМ прошел огромный путь, но вовсе не остановился. И на сегодняшний день не является какой-то отдельностоящей штукой, а отлично взаимодействует со множеством других инструментов, фреймворков, шаблонизаторов, etc.
БЭМ не предполагает никаких супер-блоков, блоки можно без ограничейний вкладывать друг в друга.
Про обертки есть пост на форуме на bem.info: https://ru.bem.info/forum/656/
Загляните в исходники bem-components: https://github.com/bem/bem-components/blob/v2/design/common.blocks/button/_theme/button_theme_islands.styl
Мы спокойно используем каскады и переопределяем стили других блоков, когда это обосновано.
Загляните, наконец, в описание методологии: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Там явно написано, почему БЭМ не рекомендует вложенные селекторы и приводятся примеры, когда это оправдано.
В душу начинает закрадываться сомнение, что в Яндексе тот же БЭМ, который рисуют в своем воображении благодарные пользователи ;)
Про придурки и глупо я услышал. А вот какие проблемы возникнут на этом злополучном сайте, где кот наплакал и не планируется масштабируемости — нет. Расскажите?
Если вы заявляете, что «Класс menu-list__link не имеет отношения к семантике, вообще», видимо, стоит определиться с тем, что мы подразумеваем под термином «семантика». Подсмотрел в Википедии такое определение: «Семантика языка — это смысловое значение слов». Вроде по menu-list__link вполне понятно, какой смысл вкладывал автор?
Вы упускаете важный момент: БЭМ про компоненты (примерно как web components).
Рассматриваемый пример говорит следующее:
link — это ссылка. Универсальная, используемая совершенно произвольно. Полный аналог тега <a>. Следующий класс menu-list__link говорит, что данная ссылка кроме прочего является частью универсального меню (семантически очень похоже на семантику тега <li>, но уже чуть более конкретно). Кроме того эта ссылка имеет определенное свойство menu-list__link_size_small (аналогия — пропсы и стейты в Реакте).
Отличие от варианта с menu-list__full-article-link_secondary (который, конечно, тоже вполне имеет право на жизнь) в том, что мы однажды на проекте определили, как ведут себя абстрактные ссылки, отдельно — как ведет себя меню, а дальше применяя композицию, можем собирать из таких кирпичей что-то более сложное.
Т.е. это некая середина между совсем уж абстрактными <a> и <li>, у которых семантики немногим больше, чем у <div> и <span>, но все-таки с шансом на реиспользование и возможность при рефакторинге менять код для всех ссылок сразу (да, препроцессоры тоже позволяют этого добиться, вопрос лишь в том, что современный компонент — это сумма стилей, скриптов и разметки, а тут уже препроцессоров не хватает).
Ну а довод вида «то что данный линк лежит внутри меню мы можем узнать просто посмотрев на DOM» как раз и является иллюстрацией того, что с БЭМ исчезает необходимость смотреть в DOM или, наоборот, правя HTML подсматривать в стили, чтобы понять, что это за компонент. Это как называть переменные осмысленно, вместо i, j, k — тоже ведь можно по коду понять, что i хранит данные пользователя, j — флаг авторизации, а k — цену товара.
Так все-таки, какие проблемы возникают на этом обычном сайте с одним единственным шаблоном из-за подчеркиваний?
А то столько придурков убеждены, что БЭМ — норм (http://webstandardsdays.ru/2014/05/24/pres/bem-ok)…
Приведу такой неслучайный список сайтов, сверстанных по БЭМ:
http://www.microsoft.com/ru-ru/azure/wizard/
http://mymail.my.com/ru/
http://sheben96.ru/
http://smartpack.pro/
Они ведь ничего общего с Яндексом не имеют. Скажите, почему БЭМ-методология для них сработала?
Я время от времени слышу, что Яндекс агрессивно продвигает БЭМ. В частности об этом сказал автор поста, zapolnoch и AmdY.
Расскажите, пожалуйста, что вы понимаете под агрессивным продвижением?
Я слежу за этой темой и за последний год слышал про пару докладов на яндексовых же Субботниках, еще пару на других конференциях от яндексоидов и, наверное, пяток докладов от людей не из Яндекса, пару статей на Хабре и, вроде, всё. Зато последнее время про БЭМ регулярно пишут западные разработчики: https://www.google.com/search?q=bem+methodology&lr=lang_en
Можно сформулировать так: если хватает ресурсов на разработку и поддержку двух специализированных версий, то, думаю, очевидно, что такие версии будут работать эффективнее. Если же ресурсов нет, то адаптивная версия, конечно, имеет право на существование.
Тот факт, что БЭМ изобрели в Яндексе не гарантирует, что все разработчики в любой момент времени используют его в полной мере.
Причин может быть много. Например, разработчик недавно вышел на работу и еще не разобрался. Или проект старый, но работает и переписывать его просто из любви к искусству не хватает рук. И так далее.
Если же смотреть конкретно на приведенные примеры, то предположу, что причины такие (дисклеймер: я являются разработчиком ya.ru и могу ошибаться по всем пунктам):
Проект использует общую библиотеку блоков (со свойственным всем долгоживущим общим решениям количеством legacy), но оформление ссылок на ya.ru отличаются от их оформления на остальном портале. Здесь разработчики просто повышают вес селекторов.
Выглядит как стили для оформления отладочной информации, используемой в девелопменте. Думаю, странно предъявлять к ним какие-либо требования (другой вопрос, что если я прав на счет их предназначения, то их бы в идеале вообще вырезать при сборке в прод).
В целом же ya.ru следует БЭМ-методологии гораздо ближе, чем ряд других сервисов Яндекса. Однако это обычное дело: все знают, что долго сидеть за компьютером и кушать жареное вредно, а заниматься спортом — полезно, но далеко не всегда следуют хорошим рекомендациям ;)
Google:
https://github.com/google/material-design-lite/wiki/Understanding-BEM
https://developers.google.com/web/fundamentals/performance/rendering/reduce-the-scope-and-complexity-of-style-calculations
Adobe:
http://topcoat.io/
Гайды от правительства США:
https://playbook.cio.gov/designstandards/getting-started/
Еще гайды:
http://www.joelambert.co.uk/article/bem-guidelines/
Снова гайды:
http://cssguidelin.es/
https://github.com/search?utf8=✓&q=bem — более 2k репозиториев по запросу bem
https://www.npmjs.com/search?q=bem — 600 пакетов по запросу bem
Статьи:
http://www.integralist.co.uk/posts/bem.html
http://blog.kaelig.fr/post/48196348743/fifty-shades-of-bem
https://css-tricks.com/bem-101/
http://montagestudio.com/blog/2013/10/24/BEM-syntax-with-ux-in-mind/
http://webdesign.tutsplus.com/articles/an-introduction-to-the-bem-methodology--cms-19403
https://medium.com/@andersonorui_/bem-sass-and-bootstrap-9f89dc07d20f#.rxjgrtbmt
http://www.creativebloq.com/css3/create-modular-and-scalable-css-9134351
http://code.tutsplus.com/articles/how-were-using-modules-to-organize-our-front-end-code--cms-22702
https://davidwalsh.name/starting-css
https://www.viget.com/articles/bem-multiple-modifiers-and-experimenting-with-attribute-selectors
http://www.juliecameron.com/blog/2013/11/06/bem-naming-for-sass-color-variables-what1/
https://www.bensmithett.com/bem-modifiers-multiple-classes-vs-extend/
http://blog.8thlight.com/nelsol-batalla/2014/08/01/bem-basics.html
http://www.sitepoint.com/bem-smacss-advice-from-developers/
http://blog.14islands.com/post/70395374262/our-principles-for-bem-sass
http://vanseodesign.com/css/block-element-modifier/
http://blog.moove-it.com/mastering-css-bem-and-itcss/
И так далее. В среднем блогмониторинг приносит пару новых статей про БЭМ в день.
Ну а из местных костылятелей табличного говнокода, кроме Яндекса могу предложить к изучению опыт
* mail.ru (https://habrahabr.ru/company/mailru/blog/250783/ + https://habrahabr.ru/company/mailru/blog/142193/ + https://habrahabr.ru/company/mailru/blog/263221/)
* http://www.rambler.ru/
* Альфа-банка (https://github.com/alfa-bank-dev/ui)
* http://learn.javascript.ru/
Ну и так далее.
PS: вы в предыдущем комментарии упомянули годные практики, которым БЭМ противоречит. Поделитесь?
Так ведь это… я и для небольших проектов никакого вреда от применения БЭМа не вижу. Он есть? :)
Что до тулсета, то опять же, мы все время твердим, что БЭМ — штука модульная, можно брать по частям.
> не путать БЭМ с вёрсткой по БЭМ
Звучит примерно как не путать чаепитие с чайной церемонией ;)
Предполагается, что есть такие тонкие ценители, которые могут определить ту грань, когда вот только что была верстка по БЭМ и тут опа-па и стал БЭМ?
Я, конечно, догадываюсь, что под этим разделением понимают использование JS фреймворка, оперирующего блоками, декларативного шаблонизатора, опять же работающего с блоками, и сборки, понимающей, как собрать нужные блоки с файловой системы в общий бандл. Но вот, скажем, стали мы собирать БЭМ-проекты на gulp (https://ru.bem.info/forum/782/) или, допустим, Webpack (https://ru.bem.info/forum/774/) — это теперь не БЭМ, а верстка по БЭМ? :)
> для новичка поезд с легким освоением деталей уже ушел
На самом деле у нас движение в противоположную сторону. Мы планомерно упрощаем документацию (да и инструментарий), выпиливаем сложное, добавляем простые примеры и пытаемся учитывать конструктивную критику и повторяющиеся вопросы на форуме.
Сейчас методологический раздел https://ru.bem.info/method/ содержит те самые 5 страниц + историю появления, так что поводов для паники быть не должно. Но мое предложение в силе — если есть конкретные моменты, которые звучат непонятно — буду рад про них узнать и улучшить.
> Но пост в клубе БЭМ за 2009 год не отменяет того факта, что только пару недель назад один американский немец сказал мне «пишем только на БЭМ, без вопросов, RTFM»
Вот, скажем, http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/ англоязычный пост за январь 2013, где Гарри Робертс ссылается на Николаса Галлахера и делится своими соображениями про БЭМ.
> Но в доках есть строгие ноты по поводу других стилей написания CSS. Уверен, вы легко найдете примеры.
Смотря что вы подразумеваете под «стилем написания CSS». В документации на bem.info приводятся примеры разных вариантов нейминга, разных схем организации файловой структуры, примеры с вложенными селекторами, в общем, все то, про что вы в статье пишите. Однозначно мы, разве что, утверждаем, что селекторы на id не нужны никогда ;)
Если смотреть на частности, то Web Components достигает этого специальными требованиями к браузерному API, а текущие реализации БЭМ — тем фактом, что JS использует те же селекторы, что и CSS. Плюс, в зависимости от реализации, добавляются еще всякие хелперы про установку/снятие модификаторов, чтобы было удобно выражать состояние компонента (как state в Реакте, только используется с 2008 года), плюшки про подписку на событие изменения модфикаторов и прочие полезности. Но еще раз повторюсь, что это уже вопрос конкретного решения, которое вы будете использовать, методология же говорит лишь про расположение на файловой системе и то, что следует использовать общие селекторы на блоки/элементы, а состояние выражать через модификаторы.
Если речь про структурирование на файловой системе, то очевидно, что класть JS можно по признаку того, что это JS в одну папку (либо делать в ней подпапки при желании). А можно, как рекомендует БЭМ-методология, класть JS, описывающий поведение блока, в папку с этим блоком.
Было
styles/
button.css
input.css
js/
button.js
input.js
Так делает, например, Бутстрап.
А по БЭМ станет
button/
button.css
button.js
input/
input.css
input.js
При необходимости переиспользовать эти блоки в новом проекте не придется искать их ошметки в разных папках — все рядом.
Ну и рано или поздно вам понадобится написать юнит-тесты для этих блоков, какую-то документацию, картинки сложить — они тоже естественным образом попадут в эти папки и все останется стройно и логично.
Подробно про все это опять-таки есть на bem.info, со всеми возможными вариантами (пишу на случай, если кто-то опять захочет сказать, что в БЭМ строго и ни шагу в стороны — вариантов предостаточно): https://ru.bem.info/method/filesystem/
А если речь про написание собственно кода, то могу предложить вот такой пост на тему для начала https://ru.bem.info/forum/163/
Дальше можно смотреть в сторону https://github.com/hoho/jquery-bem
А если хочется по-настоящему серьезно подойти к вопросу, то https://ru.bem.info/technology/i-bem/
Пользоваться не доводилось. Речь о нем?
Попробую аргументировать.
> BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом
Можно, пожалуйста, ссылки и цитаты с bem.info или какой-либо статьи/выступления от Яндекса, где рекомендации как-то противоречат здравому смыслу или как-то мешают на небольших проектах?
Мы тут некоторое время назад попросили у наших коллег из Поиска поискать в дампе всего интернета сайты, которые используют верстку по БЭМ и чиселка получилась о-о-очень нехилая.
Ну и я лично знаю немало студий и даже фрилансеров-одиночек, которые используют БЭМ и довольны.
> И да, то самое чувство, когда читаешь официальные доки по BEM.
Буду очень благодарен, если ткнете носом в непонятные моменты документации.
Если они и правда до сих пор имеют место быть (мы постоянно работаем над улучшением документации), то с вашей помощью сможем улучшить и новичкам станет легче жить.
> 2015: BEM
Например, вот Я.Субботник 2011 — https://events.yandex.ru/lib/talks/217/
А вот пост в клуб БЭМ за 2009: https://ru.bem.info/forum/-46/
Так что все началось сильно раньше Бутстрапа и примерно в тот момент, когда в интернетах стало модно верстать семантично и валидно ;)
> к другим методологиям в глазки не заглядывать, свой HTML руками не трогать, чужой CSS домой не приводить.
Покажите, где вы про это узнали? Я примерно на каждом докладе рассказываю о том, как БЭМ уживается с любыми другими библиотеками (тем же Бутстрапом при желании и делюсь ссылками на решения, где БЭМ объединяют с Реактом, Ангуляром, you-name-it).
И даже HTML, грешным делом, бывает руками пишу, хотя и в самом деле есть способы поэффективнее ;)
> Развидеть двойное подчеркивание
Тут, пожалуй, сложно не согласиться, тем более что ровно про эту возможность подробно написано на bem.info в разде про нейминг: https://ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Там же приводится ссылка на инструмент, позволяющий писать вообще как угодно.
> Лаконичные модификаторы
На первый взгляд звучит неплохо, но есть проблема: https://ru.bem.info/faq/#Почему-в-БЭМ-не-рекомендуется-использовать-комбинированные-селекторы-для-создания-css-правил-к-модификатору
Если для вас экономия времени на набор нескольких символов перевешивает возникающие в результате проблемы — дело ваше. БЭМ не запрещает, но «не рекомендует». И плюс-минус ваши же примеры приводятся на bem.info ;)
> Каскадность
Строгие читатели отругали нас за использование слова «каскад» не по спеке. На самом деле это про вложенные селекторы.
Так вот, тут снова БЭМ не запрещает, а говорит, что использование «нежелательно», объясняет почему и тут же приводит примеры, когда это оправдано: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Впрочем, мы регулярно пытаемся в комментариях к статьям на Хабре рассказать, как все на самом деле (например, вот тут про это же пишет Харисов https://habrahabr.ru/post/151931/#comment_5165248), но люди упорно пишут новые статьи, где говорят то же самое, что и мы, но как будто это они только что придумали, а в Яндексе зачем-то едят кактус :)
Еще немного мифов я попытался развенчать в этом посте: https://ru.bem.info/forum/158/
Настоятельно рекомендую.
PS: в комментариях одновременно говорят о том, что смешивать БЭМ и JS — плохо, но что будущее за Web Components, где, как ни странно, компонент объединяет в себе стили, поведение и шаблоны. То самое чувство, когда https://lurkmore.co/взаимоисключающие%20параграфы
1. БЭМ и инструменты — действительно разные вещи. «Если бы мне давали доллар каждый раз, когда я это повторяю...»
2. Мы написали о заморозке bem-tools летом 2014: https://ru.bem.info/forum/-659/
3. На текущий момент сборка с помощью bem-tools просто вызывает ENB под капотом.
4. На последнем хакатоне мы начали писать bem-tools 2.0 ground up (но в них по-прежнему будет использоваться ENB для сборки).
> Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
> И это совсем не обнадеживает.
Предлагаю посмотреть на происходящее чуть-чуть внимательнее. ENB — это ядро, оно просто запускает плагины.
А вот где лежат плагины: https://github.com/enb-bem/ — в организации 18 репозиториев и 19 участников, среди которых нет Марата. А в целом NPM находит 96 пакетов по запросу enb. Так что жизнь тут бьет ключом.
Справедливости ради, после того, как Марат написал ядро и базовые технологии ENB, потребовалось гораздо больше времени на то, чтобы с помощью ENB стало можно собирать все то многообразие проектов, которое собиралось на bem-tools. Эту работу подхватила команда инструментов и продолжает ее двигать. За время, пока над ней работает новая команда, сборка на ENB стала еще быстрее, заметная часть кода переехала из ядра или была переписана.
Но главное — это то, что сборка БЭМ-проектов возможна любым другим сборщиком.
Подробнее см. посты про сборку на gulp и webpack:
https://ru.bem.info/forum/782/
https://ru.bem.info/forum/774/
> Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-синтаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller
Историческая справка:
Мы начинали с XML-синтаксиса и перешли на JS.
React изначально предложили JSX, а потом добавили поддержку JS ;)
Очевидно, что вместо BEMJSON можно использовать любой синтаксис, позволяющий описать дерево. Например, вот так выглядит поддержка yaml: https://github.com/tadatuta/enb-yaml-to-bemjson/blob/master/techs/yaml-to-bemjson.js (20 строк кода), а вот так https://github.com/tadatuta/enb-html-to-bemjson/blob/master/techs/html-to-bemjson.js — можно писать прямо на HTML.
Так что это вопрос исключительно предпочтений.
Про конкретные реализации Model/Controller совсем не понял. Тут БЭМ точно ничего не навязывает, есть примеры использования с Backbone (см. http://2013.404fest.ru/reports/backbone/), реализации для Angular (https://github.com/bem-contrib/ng-bem-components) и так далее.
Кстати, все тот же React дружит с БЭМ: https://github.com/search?utf8=✓&q=bem+react
Так что да, БЭМ прошел огромный путь, но вовсе не остановился. И на сегодняшний день не является какой-то отдельностоящей штукой, а отлично взаимодействует со множеством других инструментов, фреймворков, шаблонизаторов, etc.
Про обертки есть пост на форуме на bem.info: https://ru.bem.info/forum/656/
CSSModules можно использовать вместе с БЭМ, другое дело, что «классический» БЭМ тоже более-менее решает задачу со скоупингом :)
Мы спокойно используем каскады и переопределяем стили других блоков, когда это обосновано.
Загляните, наконец, в описание методологии: https://ru.bem.info/faq/#Почему-нежелательно-использовать-вложенные-селекторы
Там явно написано, почему БЭМ не рекомендует вложенные селекторы и приводятся примеры, когда это оправдано.
В душу начинает закрадываться сомнение, что в Яндексе тот же БЭМ, который рисуют в своем воображении благодарные пользователи ;)
Вы упускаете важный момент: БЭМ про компоненты (примерно как web components).
Рассматриваемый пример говорит следующее:
link — это ссылка. Универсальная, используемая совершенно произвольно. Полный аналог тега <a>. Следующий класс menu-list__link говорит, что данная ссылка кроме прочего является частью универсального меню (семантически очень похоже на семантику тега <li>, но уже чуть более конкретно). Кроме того эта ссылка имеет определенное свойство menu-list__link_size_small (аналогия — пропсы и стейты в Реакте).
Отличие от варианта с menu-list__full-article-link_secondary (который, конечно, тоже вполне имеет право на жизнь) в том, что мы однажды на проекте определили, как ведут себя абстрактные ссылки, отдельно — как ведет себя меню, а дальше применяя композицию, можем собирать из таких кирпичей что-то более сложное.
Т.е. это некая середина между совсем уж абстрактными <a> и <li>, у которых семантики немногим больше, чем у <div> и <span>, но все-таки с шансом на реиспользование и возможность при рефакторинге менять код для всех ссылок сразу (да, препроцессоры тоже позволяют этого добиться, вопрос лишь в том, что современный компонент — это сумма стилей, скриптов и разметки, а тут уже препроцессоров не хватает).
Ну а довод вида «то что данный линк лежит внутри меню мы можем узнать просто посмотрев на DOM» как раз и является иллюстрацией того, что с БЭМ исчезает необходимость смотреть в DOM или, наоборот, правя HTML подсматривать в стили, чтобы понять, что это за компонент. Это как называть переменные осмысленно, вместо i, j, k — тоже ведь можно по коду понять, что i хранит данные пользователя, j — флаг авторизации, а k — цену товара.
А то столько придурков убеждены, что БЭМ — норм (http://webstandardsdays.ru/2014/05/24/pres/bem-ok)…
http://www.microsoft.com/ru-ru/azure/wizard/
http://mymail.my.com/ru/
http://sheben96.ru/
http://smartpack.pro/
Они ведь ничего общего с Яндексом не имеют. Скажите, почему БЭМ-методология для них сработала?
Расскажите, пожалуйста, что вы понимаете под агрессивным продвижением?
Я слежу за этой темой и за последний год слышал про пару докладов на яндексовых же Субботниках, еще пару на других конференциях от яндексоидов и, наверное, пяток докладов от людей не из Яндекса, пару статей на Хабре и, вроде, всё. Зато последнее время про БЭМ регулярно пишут западные разработчики: https://www.google.com/search?q=bem+methodology&lr=lang_en
Хотя есть и радикальные точки зрения.
Причин может быть много. Например, разработчик недавно вышел на работу и еще не разобрался. Или проект старый, но работает и переписывать его просто из любви к искусству не хватает рук. И так далее.
Если же смотреть конкретно на приведенные примеры, то предположу, что причины такие (дисклеймер: я являются разработчиком ya.ru и могу ошибаться по всем пунктам):
Проект использует общую библиотеку блоков (со свойственным всем долгоживущим общим решениям количеством legacy), но оформление ссылок на ya.ru отличаются от их оформления на остальном портале. Здесь разработчики просто повышают вес селекторов.
Выглядит как стили для оформления отладочной информации, используемой в девелопменте. Думаю, странно предъявлять к ним какие-либо требования (другой вопрос, что если я прав на счет их предназначения, то их бы в идеале вообще вырезать при сборке в прод).
В целом же ya.ru следует БЭМ-методологии гораздо ближе, чем ряд других сервисов Яндекса. Однако это обычное дело: все знают, что долго сидеть за компьютером и кушать жареное вредно, а заниматься спортом — полезно, но далеко не всегда следуют хорошим рекомендациям ;)