В чем проблема «проблемы БЭМ'а»?

Вроде закончилась неделя 30 строк кода и взамен ей видимо пришла неделя "БЭМ". Причем прослеживается достаточно забавная очередность топиков:

• Верстаем веб-страничку за 15 мин.
• На БЭМ'е было бы лучше!
• Сами вы ешьте свой бем, у меня препроцессоры!

И самое интересное, как всегда, в комментариях — чистой воды холивар. Но из-за чего? Почему одни свято верят в методологию БЭМ'а, другие презирают её как узурпатора семантичности? Я попробую изложить свою точку зрения на суть всего холивара и прояснить в первую очередь для себя положение БЭМ'а в собственном мироздании.

На самом деле БЭМ'ом я заинтересовался достаточно давно, приглянулась идея, попытался в неё вникнуть, попытался применить на практике, но вот как-то не пошло, не знаю почему. Сделал несколько подходов, но в итоге мой проект превратился в жуткую мешанину из попыток внедрения БЭМ'а, и «идей кристальной семантичности HTML + CSS» (на которые я перешел, разочаровавшись в БЭМ'е). По факту меня это радует печалит до сих пор и приносит ежедневную радость боль в работе над проектом. Всплывшие статьи из ката и коментарии к ним вызвали во мне бурю эмоций по вопросам семантичности верстки, устройства браузеров, БЭМ'а, препроцессоров и всех, так или иначе касающихся темы идеологий, методологий, техник и прочего. Так как мой личный подход к применению БЭМ'а провалился, но вполне логичные обоснования применения методологии все еще бродили в голове, то в каждой статье и каждом комментарии я пытался найти истину, которая так или иначе дала бы ответы на мои вопросы и окончательно бы сформировала лично мое отношение к БЭМ'у. Как ни странно в один прекрасный момент это произошло. Как это произошло и почему я попытаюсь донести до вас.

Рассмотрим типичный холивар

Действующие лица

Семантист — отрицающий БЭМ.
Бэмер — приверженец БЭМ.

Акт I: Начало

Семантист

Напишем структуру менюшки.

<nav>
    <ul class="top-menu">
        <li><a href="/home/">HOME</a></li>
        <li class="active">ABOUT US</li>
        <li><a href="/services/">SERVICES</a></li>
        <li><a href="/partners/">PARTNERS</a></li>
        <li><a href="/customers/">CUSTOMERS</a></li>
        <li><a href="/projects/">PROJECTS</a></li>
        <li><a href="/careers/">CAREERS</a></li>
        <li><a href="/contact/">CONTACT</a></li>
    </ul>
</nav>

Менюшку мы написали, прикрутим к ней классы.

nav a {
    text-decoration: none;
}
nav ul {
    margin: 0;
    padding: 0;
}
nav li {
    list-style-position: inside;
    font: 14px 'Oswald', sans-serif;
    padding: 10px;
}
.top-menu li {
    display: inline-block;
    padding: 10px 30px;
    margin: 0;
}
.top-menu li.active {
    background: #29c5e6;
    color: #fff;
}
.top-menu a {
    color: #b2b2b2;
}

Бэмер

Вы опираетесь на структуру и каскады — у вас все развалится при первой же правке. Правильней будет так:
HTML:

<div class="b-menu">
    <a href="#" class='b-link b-link_menu b-link_menu_active' >HOME</a>
    <a href="#" class='b-link b-link_menu' >ABOUT US</a>
    <a href="#" class='b-link b-link_menu'>SERVICES</a>
    <a href="#" class='b-link b-link_menu'>PARTNERS</a>
    <a href="#" class='b-link b-link_menu'>CUSTOMERS</a>
    <a href="#" class='b-link b-link_menu'>PROJECTS</a>
    <a href="#" class='b-link b-link_menu'>CAREERS</a>
    <a href="#" class='b-link b-link_menu'>CONTACT</a>
</div>

CSS:

.b-menu
{
    margin:0;
    padding:0;
    list-style:none; 
    width:100%;
    display:table;
    table-layout: fixed;   

}
.b-link_menu
{
    text-align:center;
    color:#bfbfbf;
    cursor:pointer;
    font-size:14px;
    height:38px;
    background-color:#f3f3f3;
    line-height:38px;
    border: 1px solid #e7e7e7;
    display:table-cell;
    text-decoration: none;
}
.b-link_menu_active
{
    color:#fefefe;
    background-color:#29c5e6;
    border:1px solid #29c5e6;
}

При таком подходе вам ничего не стоит поменять структуру HTML, не развалив при этом стили.

Акт II: Недопонимание

Семантист

Какой смысл плодить кучу классов? Не проще и не короче ли тогда прописать инлайн стили? Зачем раздувать CSS файл? Ничего не понятно!

Бэмер

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

Семантист

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

Акт III: Переход в другое измерение

Бэмер

Вы все еще пишите HTML руками? У нас ведь есть такие прекрасные элементы как bemhtml и bemjson — вы описываете классы (которые кстати говоря можно использовать многократно), их положение в структуре документа и наполнение, а тулзы за вас генерят HTML разметку, и раскладывают все по полочкам. Следовательно вам нет нужды касаться HTML напрямую.

Семантист

А зачем мне использовать какие-то тулзы? Я лучше воспользуюсь препроцессорами HTML и CSS — эффект будет тот же но кода меньше и все намного понятнее и нагляднее.

Акт IV: Развязка

Бэмер

Еще один «не въехал в БЭМ» и зачем-то приплел препроцессоры, и вообще сравнивает теплое с мягким, мы ведь предлагаем методологию, которая с успехом применяется на крупных проектах и все только за.

Семантист

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

* Многое из описание холивара нарочно утрировано, перефразированно, выдернуто из контекста и прочее для того, что бы подчеркнуть расхожесть взглядов с разных сторон.

«Проблемы БЭМ'а»

Смысл всего описанного выше холивара по сути заключается в аргументации сравнения «теплого с мягким», просто под «теплым» и «мягким» каждый разработчик также подразумевает разные абстракции. И в этом и заключается самая главная проблема БЭМ'а и не «въехавших» — авторы методологии слишком много смысла вложили в эти 3 буквы, из-за чего те кто не работал с методологией видят только её часть через «замочную скважину» своего опыта и мироздания. И для того, чтобы понять зачем вообще её придумали и в чём смысл от её применения надо перечитать кучу информации, выявить в ней причинно-следственные связи, вжиться в неё, и всё это только для того, чтобы понять «зачем?». Авторы сами вырывают куски своей методологии для аргументации и все эти разрозненные куски называют БЭМ.

С одной стороны БЭМ — это просто принципы именования классов. Сама идея «Блок Элемент Модификатор» выглядит достаточно логичной — все сущности описываем блоками .b-example и вложенными в них элементами .b-example__element, для определенных блоков и иэлементов применяем модификаторы .b-example__mod_val / .b-example__element__mod_val. И такой подход позволяет повысить наглядность классов и определять их принадлежность к блоку только по имени.

С другой стороны БЭМ — это принципы реализации независимых блоков. Отказ от каскадности классов, отказ от привязки к структуре документа, максимальная спецефичность имен классов — все это с целью привнесения безболезненности и легкости при постоянно возникающих правках, редизайнах и прочего.

И самое интересное, что чем далее развивает методология, тем больше смысла вкладывается в эти 3 буквы:

БЭМ — отказ от ручного подхода в создании структуры HTML. Описываем все используемые классы, на JSON (в данном случае на спецефичном BEMJSON) создаем структуру документа и взаимоотношения классов — специальный инструмент (bemhtml) генерирует соответствующий HTML — всё здорово и все счастливы.

БЭМ — возможность генерации JS для работы с ранее сгенерированным HTML. * По этому пункту ничего осмысленного сказать не могу, так как не раработал с ним, надеюсь знающие люди подскажут.

«Корень зла»

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

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

Логичным решением возникшей проблемы, как мне кажется, является декомпозия столь глобальной абстракции на более мелкие, с последовательным введением терминологии для каждой более мелкой абстракции («сферы БЭМ'а»), что, кстати говоря, будет также отражать идеологию БЭМ'а — независимость использования и доработки каждой из абстракций.

Вместо заключения.

Лично для себя я определился с БЭМ:

• смысл от использования независимых блоков есть, и конечно же я буду их применять;
• правила именования классов мне не особо понравился — зачастую слишком избыточно (не буду спорить, что в крупных проектах это может быть панацеей), возможно буду использовать несколько модифицированный подход;
• инструменты БЭМ'а мне кажутся избыточными, по крайней мере для моих текущих задач, возможно в будущем рассмотрю их более подробно