Блок, Элемент, Модификатор (БЭМ, BEM)

Очередная порция хоум-видео. На этот раз о том, как организовать рефакторинг большого проекта для внедрения БЭМ.

Пользователи iOS традицинно пользуются vimeo-версией: http://vimeo.com/41477433

Как раз получается что-то подобное, но в связке ember.js+sprockets+rails. Хотелось бы узнать больше о БЭМ, чтобы сделать текущий вариант лучше, а впоследствии перейти на БЭМ(либо адаптировать его под Rails - всё же есть extjs)

Компания - http://www.invisalign.com/Pages/default.aspx . Теплый приём обеспечим!

Продолжаем публикацию видео с приватного индивидуального семинара.

Теперь о том, как «завести» БЭМ на сайте с динамическим движком. На эту тему можно посмотреть сразу 2 видео.

Сначала о том, как вообще происходит преобразование данных в страницу «по БЭМ»

И материал для более глубокого изучения — как собирать всё, что относится к странице, в страничные файлы. В том числе и то, как выделять какие-то common-куски для всего проекта.

Традиционно, эти же видео хостятся на Vimeo, чтобы смотреть с iPhone и iPad:

• Как прикрутить БЭМ к «динамике»
• Сборка страницы по БЭМ

Мы залили видео выступления «b-form-button.css и b-form-button.js: История одной кнопки» с конференции РИТ 2012 в качестве, лучшем чем с iPhone на Яндекс.Видео и Vimeo.

В марте мы проввели первый индивидуальный семинар. Отвечали на вопросы ребят из Rugion.ru. Вопросы опубликованы.

Поскольку всё записывали, имеем возможность выложить наружу. Держите первое home-видео с  Вегедом о том, как взаимодействуют разработчики разных специальностей, если проект построен по БЭМ.

Это же видео опубликовано на Vimeo (рекомендуем для пользователей iOS).

Если вы хотите следить за всем, что происходит в организации bem на github.com, добавьте себе в ридер этот feed: https://github.com/bem.atom

Бэм, как методология, не обязывает использовать bemhtml, а как следствие, хочется сделать так, как будет проще,

Серверный шаблонизатор.

Итак, хочется не вводить новый шаблонизатор, а использовать уже существующий.

1. V8-шаблонизатор внутри asp.net

   тут нужно: 

• разобраться как прикрутить V8;
• исследовать производительность;
• а стоит ли оно того? интуитивно кажется, что нет

2. не bemhtml-шаблонизатор (в моем случае asp.net или asp.net mvc)

  плюсы:

• блоки могут использовать разработчики, которые не знают ничего про верстку и бэм.
• из коробки intellisense + reSharper by JetBrains (в IDE Visual Studio)
• можно внедрять бэм-блоки на страницы, собранные не по бэм-методологи, а в качестве переходного шага это просто необходимо
• можно писать plain-html внутри блока

   минусы:

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

3. Отказаться от asp.net, но это нереально (по крайне мере пока или так будет всегда) .

есть ли у вас реализации не bemhtml-шаблонизаторов?


P.S.    архитектура вполне стандартная:
           browser --> nginx-балансировщик --> фронтенды (IIS + шаблонизатор asp.net) --> бэкенды

P.P.S. сейчас мы пошли вторым путем


Шаблонизация в браузере.

Шаблонизаторов уже существует множество, особенно на основе jquery. А что, насчет использования bemhtml, можно об этом подробнее ?

• в продакшене используете?
• как отлавливаются ошибки?
• какие-то оценки скорости применения по сравнению с jquery.tmpl или подобными шаблонизаторами ?

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

Как стоит верстать / разбивать на блоки?

У меня возникли следующие варианты (с их недостатками):

1. Сверстать как один блок. Проблемы начнутся, когда в новой версии дизайна один из этих блоков вдруг начнёт выглядеть по-другому или, что ещё хуже, чуть по-другому. Тогда потребуется мешать лапшу из модификаторов и каскадов, что не гуд. Ещё недостаток - как назвать этот блок?..

2. Сверстать как два разных блока. Недостаток - дублирование кода; зато внесение изменений в один из блоков не затронет другой. И с называнием проще.

3. Сверстать как два разных блока, но вынести общие визуальные свойства в примеси. Решается проблема дублирования, но добавляется вот такой ужас: nav.sidebar-menu.i-rounded.i-bordered.i-dashed.i-something-else.

Как бы вы поступили и почему?

Недавно о нас написал Nicolas Gallagher. Ссылка быстро разошлась по блогам и твитам, что дало почти тысячу просмотров на портале bem.github.com.

Nicolas дал ссылку на старый манифест про BEM. Интереснее всего реакция англоязычной аудитории, которая с нами только знакомится.  16 марта манифест посетили 262 уника, и 215 из них перешли по ссылке на фундаментальную статью. 97 реально читали. Такой вывод я делаю из того, что они провели с открытой страницей более 3 минут.

Но особенно радуют долгосрочные результаты.

Как сами видите, после «всплеска» посещаемость выросла в два раза.

Изменился и портрет пользователя. Раньше среди наших пользователей было 21% иностранцев. Сейчас рускоязычная аудитория по-прежнему лидирует, но европейцы и американцы наступают стремительно: их уже 45%. Разница между этими измерениями — неделя. Напомню, что увеличилась и общая посещаемость, так что в абсолютных цифрах нерусскоговорящих разработчиков стало в 4 раза больше.

Несмотря на то, что информации на английском языке у нас меньше, пользователи относятся к ней внимательнее. Не буду утомлять цифрами. Просто вспомните про то, что такое интеграл, и посмотрите на картинку:

А, да: пост написан не просто так. Во-первых, он в предверии большого события, о котором я вам пока не расскажу. А во-вторых, напоминаю, что наши проекты Open Source. И даже если вы не чувствуете в себе сил писать в них код, у вас всё равно есть шанс прославиться поучаствовать. Например, написать немного на английском про bem-bl. Для этого нужно форкнуть репозиторий, найти *.ru.wiki файлы и сделать из них *.en.wiki. И первый же pull request сделает вас контрибьютером :-)

Сейчас можно встретить самые разные варианты записи BEM-сущностей в параметрах методов, например:
BEM.DOM.decl({ block : 'block', modName : 'mod', modVal : 'val' }, ...);
BEM.DOM.decl({ name : 'block', modName : 'mod', modVal : 'val' }, ...);
this.liveBindTo({ elemName : 'elem', modName : 'mod', modVal : 'val' }, ...);
this.findBlockInside({ blockName : 'block', modName : 'mod', modVal : 'val' }, ...);

Теперь все параметры во всех методах, описывающие BEM-сущности, будут приведены к единому виду:
{ block : 'имя_блока', elem : 'имя_элемента', modName : 'имя_модификатора', modVal : 'значение_модификатора' }
То есть исчезают name, blockName, elemName. Остаются только block, elem, modName, modVal.

Таким образом, предыдущие примеры будут выглядеть так:
BEM.DOM.decl({ block : 'block', modName : 'mod', modVal : 'val' }, ...);
this.liveBindTo({ elem : 'elem', modName : 'mod', modVal : 'val' }, ...);
this.findBlockInside({ block : 'block', modName : 'mod', modVal : 'val' }, ...);


Строчные шоткаты для BEM-сущностей без модификаторов, конечно же, остаются.

Старый формат также пока поддерживается, но, в дальнейшем, стоит придерживаться единого стиля.

Часто встречается вопрос: как поступать, когда не хватает возможностей BEM.DOM.init и BEM.DOM.update? Например, когда нужно вставить какой-то контент перед/после определенного элемента или добавить в начало/конец элемента и инициализировать блоки во вновь вставленном контенте.

Предлагалось использовать jQuery-методы для работы с DOM, а потом использовать BEM.DOM.init.

Теперь в i-bem.js появились дополнительные шоткаты-хелперы для наиболее часто возникающих ситуаций:

BEM.DOM.append(ctx, content)
BEM.DOM.prepend(ctx, content)
BEM.DOM.before(ctx, content)
BEM.DOM.after(ctx, content)