Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Посмотрите, вот большой проект на BEM ( BEMJSON, BEMHTML, i-bem.js)
github.com/alexbaumgertner/hunter-boat
И при этом это не в Яндексе или еще где, а в небольшой студии.
github.com/alexbaumgertner/hunter-boat
И при этом это не в Яндексе или еще где, а в небольшой студии.
Не знаю насчет БЭМ, но вкладывать блоки в строчные элементы не очень правильно.
<span class="header__column header__column_position_left">
<div class="logo">
HUNTERBOAT
</div>
</span>
c html5 доктайпом все ок будет. )
валидатор в отличии от спеки не переписывают каждый день, так что — пока видим как ошибку.
Читаем спеку
Most elements that are categorized as phrasing content can only contain elements that are themselves categorized as phrasing content, not any flow content.
Расхождений с валидатором не вижу
Most elements that are categorized as phrasing content can only contain elements that are themselves categorized as phrasing content, not any flow content.
Расхождений с валидатором не вижу
Мне кажется это как с вопросом о тупоконечниках и остроконечниках у Свифта…
Я не хочу доказать, что БЭМ или неБЭМ это круто.
Я хочу оптимальным образом решать свои задачи — разрабатывать интерфейс так, чтобы не было мучительно больно.
bem-tools + BEMJSON, BEMHTML, i-bem.js решили мою задачу.
Очень рекомендую завтра (29 ноября) посмотреть трансляцию доклада Димы Кушникова tech.yandex.ru/events/bemup/spb-bemup/talks/1415/
Я хочу оптимальным образом решать свои задачи — разрабатывать интерфейс так, чтобы не было мучительно больно.
bem-tools + BEMJSON, BEMHTML, i-bem.js решили мою задачу.
Очень рекомендую завтра (29 ноября) посмотреть трансляцию доклада Димы Кушникова tech.yandex.ru/events/bemup/spb-bemup/talks/1415/
Ну вот кто то великолепно всё решает и без этих тулс и подходов. :) На вкус и цвет все фломастеры разные.
Я вот пока даже Stylus/LESS не смог нигде на продакшене применить, хотя трогал и даже нравилось. ИМХО время вас рассудит, слишком это свежие технологии.
Я вот пока даже Stylus/LESS не смог нигде на продакшене применить, хотя трогал и даже нравилось. ИМХО время вас рассудит, слишком это свежие технологии.
Я и не спорю, что каждый разработчик выбирает тот инструмент, который выбирает.
Про БЭМ ходит много легенд, многие, думая что он про именование css-классов немного ошибаются.
А препроцессоры лично я не употребляю по причине habrahabr.ru/post/203838/#comment_7035398
Про БЭМ ходит много легенд, многие, думая что он про именование css-классов немного ошибаются.
А препроцессоры лично я не употребляю по причине habrahabr.ru/post/203838/#comment_7035398
О всём хорошем в БЭМе можно сказать одним предложением «Разделяй и властвуй».
После опыта с ним сложно стать «Семантиком» из вашей статьи, хотя иногда нравится верить что это не единственный существующий способ разработки интерфейсов на больших проектах без боли.
После опыта с ним сложно стать «Семантиком» из вашей статьи, хотя иногда нравится верить что это не единственный существующий способ разработки интерфейсов на больших проектах без боли.
«И самое интересное, как всегда, в комментариях — чистой воды холивар. „
А чем же эта статья, в которой 50% текста это прошлый холивар и еще 50% чистой воды философия, отличается от монохоливара? То, что БЭМ это уход от каскадности говориться в каждой статье, зачем капитанить опять и опять?
Если хотите защитить эту идею, то приведите хороший реальный пример, примерно как было в статье -Верстаем страницу по БЭМу. Хотя пример там очень не удачный (ИМХО), но попытка не пытка. Пример, из реального проекта, где данная методология спасла вам часы времени и вы были жутко рады, что наконец-то дожили до того момента, когда она действительно дала пользу. Ведь кому нужна эта философия? Народ хочет реальный пример, а не абстракцию. Хватит пинать воздух!
И почему все говорят будто БЭМ это панацея для больших проектов? (мысли вслух)
Заходим к Лебедеву на сайт, берем случайные проекты:
megamall.ru/
www.gazprom.de/
rkz.ru/
www.verona-mobili.ru/ — в коде какой-то частичный БЭМ
www.ma-ma.ru/ — единый из вышестоящих, где все выглядит по БЭМу.
Из 5 сайтов 1 на чистом БЭМе. Все проекты вполне большие. Выходит они не ценят время или просто дурачки? )
Причем судя по последнему сайту у них видать верстальщики как-то непонятно меняются. Фамилии в исходниках css разнятся.
А чем же эта статья, в которой 50% текста это прошлый холивар и еще 50% чистой воды философия, отличается от монохоливара? То, что БЭМ это уход от каскадности говориться в каждой статье, зачем капитанить опять и опять?
Если хотите защитить эту идею, то приведите хороший реальный пример, примерно как было в статье -Верстаем страницу по БЭМу. Хотя пример там очень не удачный (ИМХО), но попытка не пытка. Пример, из реального проекта, где данная методология спасла вам часы времени и вы были жутко рады, что наконец-то дожили до того момента, когда она действительно дала пользу. Ведь кому нужна эта философия? Народ хочет реальный пример, а не абстракцию. Хватит пинать воздух!
И почему все говорят будто БЭМ это панацея для больших проектов? (мысли вслух)
Заходим к Лебедеву на сайт, берем случайные проекты:
megamall.ru/
www.gazprom.de/
rkz.ru/
www.verona-mobili.ru/ — в коде какой-то частичный БЭМ
www.ma-ma.ru/ — единый из вышестоящих, где все выглядит по БЭМу.
Из 5 сайтов 1 на чистом БЭМе. Все проекты вполне большие. Выходит они не ценят время или просто дурачки? )
Причем судя по последнему сайту у них видать верстальщики как-то непонятно меняются. Фамилии в исходниках css разнятся.
Проекты на полном стеке BEM (прототипирование BEMJSON + BEMHTML + js на i-bem.js):
nautilusdent.ru/
hunterboat.ru/ (исходники github.com/alexbaumgertner/hunter-boat)
planetasid.ru/ (исходники github.com/alexbaumgertner/planeta-sid)
krechi-sila.narod.ru/ (исходники могу выложить сегодня)
zapravka-gaza.ru/ (+ вестка не по BEM от верстальщика, принявшего проект)
Особо рады сервер-сайд программисты, когда видят верстку, в которой сразу ясно какие данные где отображаются (код www.nautilusdent.ru/):
nautilusdent.ru/
hunterboat.ru/ (исходники github.com/alexbaumgertner/hunter-boat)
planetasid.ru/ (исходники github.com/alexbaumgertner/planeta-sid)
krechi-sila.narod.ru/ (исходники могу выложить сегодня)
zapravka-gaza.ru/ (+ вестка не по BEM от верстальщика, принявшего проект)
Особо рады сервер-сайд программисты, когда видят верстку, в которой сразу ясно какие данные где отображаются (код www.nautilusdent.ru/):
<div class="person">
<div class="person__photo-wrap">
<img class="person__photo" src="/images/com_fwgallery/files/975/team1.png" alt="Александр Поболь">
</div>
<div class="person__title">
Александр Поболь
</div>
<div class="person__description">
Генеральный директор. Техник высшей категории. Награждён почётными грамотами и дипломами, отмечен грамотой министра здравоохранения.
<br>
Опыт работы с 1984 г.
</div>
<div class="person__link-to-all">
<a class="b-link" href="http://nautilusdent.ru/pobol-aleksandr.html">
Все работы
</a>
</div>
</div>
На первом сайте какая-то ерунда в последнем Хроме postimg.org/image/bbf8tmi4d/
Некоторые ссылки и слайдеры вовсе не работают.
На hunterboat.ru/ не работает «обратный звонок» и еще пара кнопок.
Это все бета версии?
Особо рады сервер-сайд программисты
Т.е. все дело в сервер-сайд программистах? Это прям по Фрейду. Говорили о верстальщиках, а рады в итоге сервер-сайдники. ))
Некоторые ссылки и слайдеры вовсе не работают.
На hunterboat.ru/ не работает «обратный звонок» и еще пара кнопок.
Это все бета версии?
Особо рады сервер-сайд программисты
Т.е. все дело в сервер-сайд программистах? Это прям по Фрейду. Говорили о верстальщиках, а рады в итоге сервер-сайдники. ))
Я работаю в команде (распределенная по нескольким городам, я в Великом Новгороде, программист в Питере) и для меня удобство всех участников стоит не на последнем месте.
А вы работаете по принципу «наверстал и забыл»?
А вы работаете по принципу «наверстал и забыл»?
Я не совсем понял ваш предыдущий коммент со списком сайтов. Свой список я выдал, дабы показать, что самая крупная студия России с самыми бешенными расценками, использует для довольно немалых сайтов те средства, которые считает нужными, и БЭМ у них не в приоритете. Вы же пытаетесь — на случайно взятых примерах что-то доказать. Что по этим примерам мы должны понять?
Зашел на сайт той студии.
16.04.13 — nautilusdent.ru/
сайт на БЭМе
22.04.13 — www.spbgaz.com/
не на БЭМе, с довольно стремной версткой, в которой даже главное меню не потрудились выделить в отдельный класс. CSS «хорош»:
20.05.2013 — zapravka-gaza.ru
опять по БЕМу.
Насчет www.spbgaz.com/ —
header nav
{
position: absolute;
height: 42px;
top: 113px;
left: 25px;
width: 996px;
border: 1px solid #f7ab2e;
}
Это стажер или нормальная работа студии — неделю через неделю писать то на БЭМе, то по-обычному и криво? И нет, это не попытка зацепиться за какой-то косяк и чем-то обидеть, мне реально интересно, что это за верстальщик/и у вас и почему он/и так работают.
А вы работаете по принципу «наверстал и забыл»?
Забавный вопрос. Не хочу показаться занудой, но — вы верстаете по БЭМу и не забываете? )
Зашел на сайт той студии.
16.04.13 — nautilusdent.ru/
сайт на БЭМе
22.04.13 — www.spbgaz.com/
не на БЭМе, с довольно стремной версткой, в которой даже главное меню не потрудились выделить в отдельный класс. CSS «хорош»:
20.05.2013 — zapravka-gaza.ru
опять по БЕМу.
Насчет www.spbgaz.com/ —
header nav
{
position: absolute;
height: 42px;
top: 113px;
left: 25px;
width: 996px;
border: 1px solid #f7ab2e;
}
Это стажер или нормальная работа студии — неделю через неделю писать то на БЭМе, то по-обычному и криво? И нет, это не попытка зацепиться за какой-то косяк и чем-то обидеть, мне реально интересно, что это за верстальщик/и у вас и почему он/и так работают.
А вы работаете по принципу «наверстал и забыл»?
Забавный вопрос. Не хочу показаться занудой, но — вы верстаете по БЭМу и не забываете? )
В студии не один верстальщик, www.spbgaz.com/ — делал не я.
Верстаю по БЭМу и забываю. Нет нужды помнить все эти nav > ul > li.
Вот вы, никогда не видели верстку и тут видите такой код:
Сложно понять, где будет имя пользователя?
Вот вы, никогда не видели верстку и тут видите такой код:
<div class="user-thumb">
<div class="user-thumb__name"></div>
</div>
Сложно понять, где будет имя пользователя?
«Нет нужды помнить все эти nav > ul > li.»
Хм, а кто так делает? Я например из БЭМа подчеркнул полезность в том, что отдельные элементы, списки, nav и прочее проще сразу вынести в класс и обращаться напрямую, нежели творить конструкции типа nav > ul > li > ul > li > a + span
Причем такие конструкции далеко не всех пугают и не считаются чем-то ужасным. Стоит хотя бы взять пару книг по CSS и сравнить как разные авторы кодят html c css.
Хм, а кто так делает? Я например из БЭМа подчеркнул полезность в том, что отдельные элементы, списки, nav и прочее проще сразу вынести в класс и обращаться напрямую, нежели творить конструкции типа nav > ul > li > ul > li > a + span
Причем такие конструкции далеко не всех пугают и не считаются чем-то ужасным. Стоит хотя бы взять пару книг по CSS и сравнить как разные авторы кодят html c css.
У вас тут postimg.org/image/bbf8tmi4d/ js не отключен случаем?
Какой-то у вас семантист злой и тупой получился.
В данный момент вся сложность в том, что бэмисты гордятся своими bemhtml и bemjson, а реальное преимущество в них ощущается не сильно. А они уже привыкли так.
А семантики своим jade|haml|slim + less|sass|stylus, которые тоже очень удобны. И они не видят смысла делать двух-трех уровневую структуру блоков.
В данный момент вся сложность в том, что бэмисты гордятся своими bemhtml и bemjson, а реальное преимущество в них ощущается не сильно. А они уже привыкли так.
А семантики своим jade|haml|slim + less|sass|stylus, которые тоже очень удобны. И они не видят смысла делать двух-трех уровневую структуру блоков.
Не было умысла выставить кого-либо в негативном свете, извиняюсь, если это так выглядит.
Я не горжусь, я рассказываю как мне удобнее и привожу примеры реального кода, а не суждений и мнений.
И никого не заставляю все бросить и пересесть на BEMJSON.
Суть моих комментариев в том, что многие разработчики критикуют не БЭМ, а свое представление о нем.
Посмотрите все посты про БЭМ выше — там про css. Я же говорю, что методология гораздо шире и вообще не про именование.
И никого не заставляю все бросить и пересесть на BEMJSON.
Суть моих комментариев в том, что многие разработчики критикуют не БЭМ, а свое представление о нем.
Посмотрите все посты про БЭМ выше — там про css. Я же говорю, что методология гораздо шире и вообще не про именование.
у меня нет суждений и мнений в комментарии, я просто объективно взглянул на ситуацию :)
если интересует мое личное мнение (в чем я сомневаюсь) — бэм избыточен в своей сложности для 99% проектов. Почему? Да потому что нет необходимости синхронизации отдельных команд. Нет необходимости создания библиотеки общих элементов и проблем с их совместимостью.
БЭМ — это попытка прыгнуть на пять лет вперед, радостно размахивая оперенными трехметровыми костылями
Долетели ли они до цели? Да. Ржут ли над ними? Тоже да.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов. Вот товарищ ниже пишет, как это все появлялось: куча разных команд делала кучу разной хрени, и нужно было их совместить. Когда начали совмещать — ясен хрен что div.mega-link оказался в десяти проектах разом. Поэтому нужно было внедрить префиксы класса. Теоретически можно было бы обойтись .block-name .element-name, но возникала проблема с вложенными блоками: если в родительском блоке и дочернем блоке были .mega-link, понятное дело что к потомку применялись свойства родителя.
Таким образом единственным возможным вариантом было создание классов .block_name__element_name.
Через уже небольшое время народ задолбался от монотонности разумного в общем-то процесса до такой степени, что решил упростить себе жизнь и сделал те самые bem-tools, без которых верстать уже некоторые попросту не умеют.
Вся подстава в том, что в реальности инкапсуляция классов уже существует и работает в Chrome, а с полифиллом (я сам был в шоке, если честно) — и ie10+ и FF, safari etc. Называется решение shadow DOM. По сути — это изолированная часть документа, внутри которой есть собственная логика, скрипты и стили, при этом снаружи повлиять на них практически невозможно. Через пару лет большинство подобных блочных проектов будет разрабатываться именно на базе shadow DOM, а про БЭМ будут помнить только фанатики и на тот момент — старперы, так как объективно он перестанет быть нужен. Это не «дискасс ит», это вполне логичная цепочка заключений: БЭМ создан для того, чтобы решить проблему инкапсуляции стилей, он решает ее, при этом избыточен, имеет определенный порог вхождения, увеличивает размер выходных файлов, через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию, так же решающую эту проблему, но не создающую новых.
Возможно, БЭМ трансформируется во что-то еще, но в текущем состоянии он отомрет. Хотя как промежуточная технология идеологически он хорош.
если интересует мое личное мнение (в чем я сомневаюсь) — бэм избыточен в своей сложности для 99% проектов. Почему? Да потому что нет необходимости синхронизации отдельных команд. Нет необходимости создания библиотеки общих элементов и проблем с их совместимостью.
БЭМ — это попытка прыгнуть на пять лет вперед, радостно размахивая оперенными трехметровыми костылями
Долетели ли они до цели? Да. Ржут ли над ними? Тоже да.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов. Вот товарищ ниже пишет, как это все появлялось: куча разных команд делала кучу разной хрени, и нужно было их совместить. Когда начали совмещать — ясен хрен что div.mega-link оказался в десяти проектах разом. Поэтому нужно было внедрить префиксы класса. Теоретически можно было бы обойтись .block-name .element-name, но возникала проблема с вложенными блоками: если в родительском блоке и дочернем блоке были .mega-link, понятное дело что к потомку применялись свойства родителя.
Таким образом единственным возможным вариантом было создание классов .block_name__element_name.
Через уже небольшое время народ задолбался от монотонности разумного в общем-то процесса до такой степени, что решил упростить себе жизнь и сделал те самые bem-tools, без которых верстать уже некоторые попросту не умеют.
Вся подстава в том, что в реальности инкапсуляция классов уже существует и работает в Chrome, а с полифиллом (я сам был в шоке, если честно) — и ie10+ и FF, safari etc. Называется решение shadow DOM. По сути — это изолированная часть документа, внутри которой есть собственная логика, скрипты и стили, при этом снаружи повлиять на них практически невозможно. Через пару лет большинство подобных блочных проектов будет разрабатываться именно на базе shadow DOM, а про БЭМ будут помнить только фанатики и на тот момент — старперы, так как объективно он перестанет быть нужен. Это не «дискасс ит», это вполне логичная цепочка заключений: БЭМ создан для того, чтобы решить проблему инкапсуляции стилей, он решает ее, при этом избыточен, имеет определенный порог вхождения, увеличивает размер выходных файлов, через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию, так же решающую эту проблему, но не создающую новых.
Возможно, БЭМ трансформируется во что-то еще, но в текущем состоянии он отомрет. Хотя как промежуточная технология идеологически он хорош.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов.
Вы забываете, что фронтенд — это еще и javascript. Без методологии в любом более-менее сложном проекте код быстро превращается в лапшу.
С помощью i-bem вы инкапсулируете логику работы в блоке. У вас не только css независимый, но и javascript имеет модульную расширяемую структуру, органично отражающую общую концепцию BEM.
Мне вот прямо хочется взять и дать ссылку на мой cornerJS, который позволяет инкапсулировать вообще весь код в проекте по директиво-ориентированному принципу: на добавление, удаление тэга или класса, изменение значения атрибута отрабатывает код, в который передается элемент. По-моему это куда более честная реализация инкапсуляции кода, чем БЭМ.
Первый попавшийся пример из ссылки:
вариант на директиве:
И это при очень простом коде поверх нативных событий с действительно хорошим быстродействием. Да, библиотека ie9+, но для некоторых ie8+ проектов для нее делалась ручная «дергалка» на проход по дом-дереву и выявление не обнаруженных еще элементов, которая тоже неплохо отрабатывала.
И еще — можно в любой момент просто добавить <div my-block/>, и колбэк выстрелит. Сам, без напоминаний или соблюдения структуры.
Мой выбор очевиден.
Если вам недостаточно моего личного мнения — существуют проекты mozilla x-tags(ie9+) и google polymer(ie10+), которые позволяют создавать отдельные веб-компоненты, обладающие полноценной (а не костыльной, как в БЭМе) инкапсуляцией скриптов, поддержкой кастомных событий, отслеживанием изменений атрибутов — а полимер реализаует еще и инкапсуляцию стилей.
Первый попавшийся пример из ссылки:
DOM.decl('my-block', {
onSetMod : {
'js' : {
'inited': function() {
this.bindTo('click', function(e) {
var domElem = $(e.currentTarget); // DOM-элемент, на котором слушается событие
// в данном случае то же, что this.domElem
this.setMod('size', 'big');
});
}
}
}
});
вариант на директиве:
directive('my-block', function(node){
$(node).on('click', function(e){
$(node).attr('size', 'big')
})
})
И это при очень простом коде поверх нативных событий с действительно хорошим быстродействием. Да, библиотека ie9+, но для некоторых ie8+ проектов для нее делалась ручная «дергалка» на проход по дом-дереву и выявление не обнаруженных еще элементов, которая тоже неплохо отрабатывала.
И еще — можно в любой момент просто добавить <div my-block/>, и колбэк выстрелит. Сам, без напоминаний или соблюдения структуры.
Мой выбор очевиден.
Если вам недостаточно моего личного мнения — существуют проекты mozilla x-tags(ie9+) и google polymer(ie10+), которые позволяют создавать отдельные веб-компоненты, обладающие полноценной (а не костыльной, как в БЭМе) инкапсуляцией скриптов, поддержкой кастомных событий, отслеживанием изменений атрибутов — а полимер реализаует еще и инкапсуляцию стилей.
Мне вот прямо хочется взять и дать ссылку на мой cornerJS
Лучше давайте
через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию
и
полифиллприложите пожалуйста.
github.com/polymer/ShadowDOM
пожалуйста.
На всякий случай: я до сих пор до конца не понимаю, как он работает. Но он работает, во всяком случае судя по заигрываниям с ним.
Shadow DOM полностью реализован для
Chrome Android Chrome Canary Firefox IE 10+ Safari 6+ Mobile Safari
Итого нужно дождаться:
-отмирание ie9
-отмирание android 2.3 с его браузером
так что три года я даже с запасом беру скорее.
LI.ru говорит, что ie8 у 2.1% людей, ie9 у 1.6%, safari 5 у 1.5%. Для где-то 90% браузеров это все работает уже сегодня.
В нашей команде стандарт разработки обычно предусматривает degradation до ie9, обычно это означает, что в ie9 не будут работать короткие плавные переходы на transitions, превьюшки файлов из drag-n-drop и некоторые другие мелочи, а все остальное будет, поэтому мы уже немного пробуем shadow DOM, но только в экспериментах.
пожалуйста.
На всякий случай: я до сих пор до конца не понимаю, как он работает. Но он работает, во всяком случае судя по заигрываниям с ним.
Shadow DOM полностью реализован для
Chrome Android Chrome Canary Firefox IE 10+ Safari 6+ Mobile Safari
Итого нужно дождаться:
-отмирание ie9
-отмирание android 2.3 с его браузером
так что три года я даже с запасом беру скорее.
LI.ru говорит, что ie8 у 2.1% людей, ie9 у 1.6%, safari 5 у 1.5%. Для где-то 90% браузеров это все работает уже сегодня.
В нашей команде стандарт разработки обычно предусматривает degradation до ie9, обычно это означает, что в ie9 не будут работать короткие плавные переходы на transitions, превьюшки файлов из drag-n-drop и некоторые другие мелочи, а все остальное будет, поэтому мы уже немного пробуем shadow DOM, но только в экспериментах.
del
Чтобы ответить на этот вопрос надо понимать как появился БЭМ и какие проблемы он решал.
Немного предистории. 2008-2009 год, Яндекс уже имеет многочисленные сервисы, разработкой которых занимаются отдельные команды. При этом используются разные технологические стеки. В это время сервисы отличались не только версткой, но присутствовали даже разногласия в «корпоративных» стилях оформления, например шапки. У пользователей скакала навигация, зачастую сходная и одинаковая верстка внедрялась разными командами самостоятельно, со всеми вытекающими. Чтобы побороть проблему и привести сервисы к общему виду, создается проект «Лего» — будущий БЭМ. При чем вначале речь шла только об общем каталоге блоков оформления (своеобразном «бутстрап» от яндекса. Стоят задачи:
а) систематизировать вёрстку;
б) создать каталог готовых шаблонов которые сервисы могут адаптировать с минимальными изменениями;
в) создать инструмент позволяющий интегрировать вёрстку специалистами не владеющими соответствующими навыками;
Данные задачи приводят нас к БЭМ. Блоки должны быть независимыми, ведь у сервисов например разные лайоуты. Блоки должны быть автономными. Сборка блоков должна быть конфигурируемая. Первые версии «Лего» конфигурировали верстку используя xml/xslt шаблонизацию. Потом окончательно оформилась концепция и «сложную» для понимания связку xslt/xml заменили на json конфигурации.
Яндекс не может отказать от БЭМ. Без данной концепции, поддержка многочисленных сервисов рассыпется и система деградирует в состояние 5 летней давности. Но теперь понимая какие задачи БЭМ решает, можно сделать вывод о необходимости его использования.
БЭМ хорошо подходит для поддержки действительно крупных и разветвленных проектов, совместно разрабатываемых отдельными командами, но сильно теряет в ценности при использовании на атомарных ресурсах. Всему своё место.
Немного предистории. 2008-2009 год, Яндекс уже имеет многочисленные сервисы, разработкой которых занимаются отдельные команды. При этом используются разные технологические стеки. В это время сервисы отличались не только версткой, но присутствовали даже разногласия в «корпоративных» стилях оформления, например шапки. У пользователей скакала навигация, зачастую сходная и одинаковая верстка внедрялась разными командами самостоятельно, со всеми вытекающими. Чтобы побороть проблему и привести сервисы к общему виду, создается проект «Лего» — будущий БЭМ. При чем вначале речь шла только об общем каталоге блоков оформления (своеобразном «бутстрап» от яндекса. Стоят задачи:
а) систематизировать вёрстку;
б) создать каталог готовых шаблонов которые сервисы могут адаптировать с минимальными изменениями;
в) создать инструмент позволяющий интегрировать вёрстку специалистами не владеющими соответствующими навыками;
Данные задачи приводят нас к БЭМ. Блоки должны быть независимыми, ведь у сервисов например разные лайоуты. Блоки должны быть автономными. Сборка блоков должна быть конфигурируемая. Первые версии «Лего» конфигурировали верстку используя xml/xslt шаблонизацию. Потом окончательно оформилась концепция и «сложную» для понимания связку xslt/xml заменили на json конфигурации.
Яндекс не может отказать от БЭМ. Без данной концепции, поддержка многочисленных сервисов рассыпется и система деградирует в состояние 5 летней давности. Но теперь понимая какие задачи БЭМ решает, можно сделать вывод о необходимости его использования.
БЭМ хорошо подходит для поддержки действительно крупных и разветвленных проектов, совместно разрабатываемых отдельными командами, но сильно теряет в ценности при использовании на атомарных ресурсах. Всему своё место.
С БЭМ знаком не понаслышке, работал с ним довольно много времени.
Начал читать статью и словил лютейший батхёрт от утрированных примеров и самое главное полное отсутствие рассмотрения различных кейсов, таких как рефакторинг, дебаг, приглашение нового человека на проект, перенос функциональностей, интеграцию вёрстки в сторонние проекты и т.д.
Также ничего не мешает юзать препроцессоры вместе с методологией БЭМ, также можно написать свои bemtools, написать свои шаблонизаторы/препроцессоры чтоб они генерили БЕМ-подобную структуру.
Что действительно важно, так это набор соглашений, пусть он будет не БЭМ, но он должен быть, чтоб легко показать как строится проект.
В свою очередь БЭМ несёт очень сжатое количество сущностей в себе и это сильно упрощает восприятие.
Не хочу ставить ни плюс, ни минус за статью: нет четкой постановки вопроса/задачи, нет исследования на примерах, и конечно нет сравнения результатов из примеров.
Не считаю БЭМ идеальной реализацией независимых блоков, но это одна из самых простых, наивных и надёжных конвенций. bemjson в свою очередь тоже весьма и весьма избыточен, но мы ведь о концепции говорим, а не о конкретной реализации, верно?
Начал читать статью и словил лютейший батхёрт от утрированных примеров и самое главное полное отсутствие рассмотрения различных кейсов, таких как рефакторинг, дебаг, приглашение нового человека на проект, перенос функциональностей, интеграцию вёрстки в сторонние проекты и т.д.
Также ничего не мешает юзать препроцессоры вместе с методологией БЭМ, также можно написать свои bemtools, написать свои шаблонизаторы/препроцессоры чтоб они генерили БЕМ-подобную структуру.
Что действительно важно, так это набор соглашений, пусть он будет не БЭМ, но он должен быть, чтоб легко показать как строится проект.
В свою очередь БЭМ несёт очень сжатое количество сущностей в себе и это сильно упрощает восприятие.
Не хочу ставить ни плюс, ни минус за статью: нет четкой постановки вопроса/задачи, нет исследования на примерах, и конечно нет сравнения результатов из примеров.
Не считаю БЭМ идеальной реализацией независимых блоков, но это одна из самых простых, наивных и надёжных конвенций. bemjson в свою очередь тоже весьма и весьма избыточен, но мы ведь о концепции говорим, а не о конкретной реализации, верно?
Покажите пожалуйста примеры избыточности BEMJSON. Я сравнивал с XML, последний явно избыточней.
haml лишь подслащивает HTML. Альтернативы?
haml лишь подслащивает HTML. Альтернативы?
Альтернативу можно написать самому, если возьмёте за основу нечто подобное https://github.com/jessemiller/HamlPy, справитесь за пару-тройку дней.
Вместо этого
Можно сделать нечто подобное:
Неужели не очевидна избыточность?
Вместо этого
{
block: 'b-foo',
content: [
{
elem: 'bar'
},
{
elem: 'container',
content: 'Hello World'
}
]
}
Можно сделать нечто подобное:
%b-foo
$bar
$container
' Hello World
Неужели не очевидна избыточность?
В haml на мой взгляд избавились от тегов, вроде как избыточность пропала, но и код стал менее удобочитаемый, и все равно описывается html-реализация страницы.
В BEMJSON вы можете выполнить произвольный js, например, для прототипирования:
И главное — BEMJSON он не про HTML, он про более высокий уровень абстракции — блоки.
В BEMJSON вы можете выполнить произвольный js, например, для прототипирования:
{
block: 'b-foo',
content: [
{
elem: 'bar'
},
{
elem: 'container',
content: (function() {
var contentVariants = ['Hello World', 'Hello Mars', 'Hello, Futurama'];
return contentVariants[Math.floor(Math.random() * contentVariants.length)];
}())
}
]
}
И главное — BEMJSON он не про HTML, он про более высокий уровень абстракции — блоки.
Не понимаю зачем вы мне рассказываете как работает BEMJSON, я работал в самом эпицентре БЭМеров и прекрасно понимаю и достоинства и недостатки.
Вот только почему вы не обращаете внимания что я пишу именно про синтаксис, что он избыточен, неудобен, не нагляден, и более того не типизирует входы/выходы и не даёт нам никаких статических гарантий.
Кроме синтаксиса, его не очень использовать на стороне сервера, плохо интегрируется на стороне сервера в существующие технологические стеки. И поднимать на сервере nodejs, только ради того чтоб отрендерить html, вместо того чтоб написать вменяемый компилятор декларированных блоков в любую инфраструктуру, мне видится крайне неразумным.
Плохо ли использовать js функции в коде шаблонизатора? Безусловно плохо, вы превращаете декларитивный стиль, ради которого вся эта шумиха с БЭМом и затевалась, в обычные императивные js подпрограммы.
Именно поэтому я предложил использовать как основу hamlpy, который именно что и делает — транслирует одни шаблоны в другие шаблоны. Как вы опишите поведение этого компилятора, так оно и будет работать. И да, туда можно просунуть абстракцию на уровне блоков или даже выше.
Делал ли я подобное? Да, делал, но не довёл до продакшн-реди, поэтому никому не показываю своё поделие. Более того, у меня нет проектов, где бы я мог развивать подобные решния, поэтому у меня еще и мотивация почти пропала.
Сейчас я пишу именно про user experience разработчика. Для BEMJSON он не так хорош, как мне бы хотелось и его нужно исправлять, потому как это реально неплохое, работающее решение. Я бы начал с синтаксиса, потом переписал бы декларацию стилей из css прямо в BEMJSON через миксины a la SASS/compass, ведь мы про блоки, а не про html, верно? :)
Вот только почему вы не обращаете внимания что я пишу именно про синтаксис, что он избыточен, неудобен, не нагляден, и более того не типизирует входы/выходы и не даёт нам никаких статических гарантий.
Кроме синтаксиса, его не очень использовать на стороне сервера, плохо интегрируется на стороне сервера в существующие технологические стеки. И поднимать на сервере nodejs, только ради того чтоб отрендерить html, вместо того чтоб написать вменяемый компилятор декларированных блоков в любую инфраструктуру, мне видится крайне неразумным.
Плохо ли использовать js функции в коде шаблонизатора? Безусловно плохо, вы превращаете декларитивный стиль, ради которого вся эта шумиха с БЭМом и затевалась, в обычные императивные js подпрограммы.
Именно поэтому я предложил использовать как основу hamlpy, который именно что и делает — транслирует одни шаблоны в другие шаблоны. Как вы опишите поведение этого компилятора, так оно и будет работать. И да, туда можно просунуть абстракцию на уровне блоков или даже выше.
Делал ли я подобное? Да, делал, но не довёл до продакшн-реди, поэтому никому не показываю своё поделие. Более того, у меня нет проектов, где бы я мог развивать подобные решния, поэтому у меня еще и мотивация почти пропала.
Сейчас я пишу именно про user experience разработчика. Для BEMJSON он не так хорош, как мне бы хотелось и его нужно исправлять, потому как это реально неплохое, работающее решение. Я бы начал с синтаксиса, потом переписал бы декларацию стилей из css прямо в BEMJSON через миксины a la SASS/compass, ведь мы про блоки, а не про html, верно? :)
Вот только почему вы не обращаете внимания что я пишу именно про синтаксис, что он избыточен, неудобен, не нагляден
Тут дело вкуса, я не использую препроцессоры, другие используют. Спор не конструктивный.
не типизирует входы/выходы и не даёт нам никаких статических гарантий.
Поясните пожалуйста, я не очень понял, если приведете пример, буду вдвойне благодарен.
Плохо ли использовать js функции в коде шаблонизатора? Безусловно плохо, вы превращаете декларитивный стиль, ради которого вся эта шумиха с БЭМом и затевалась, в обычные императивные js подпрограммы.
BEMJSON — это данные (шаблонизатор — BEMHTML), и в конкретном примере я показал возможность прототипирования контента страницы. Естественно, это не продакшен код.
Я бы начал с синтаксиса, потом переписал бы декларацию стилей из css прямо в BEMJSON через миксины a la SASS/compass
BEMJSON про струтуру блока, за оформление отвечает старый добрый CSS блока, не нужно смешивать структуру и оформление — это как раз хорошее, что есть в HTML+CSS. Или я вас не так понял?
Спасибо за подробные комментарии!
del
Поясните пожалуйста, я не очень понял, если приведете пример, буду вдвойне благодарен.
Например на вход в блок должна подаваться структура подобного вида:
{ title: "foo",
body: "bar" }
А подаётся
{ name: "foo",
content: "bar" }
И блок вам никогда не скажет об ошибке, а будет просто генерировать глупости всякие.
Но это простейший случай динамической типизации, а в статической типизации у вас каждый блок как-то формально заявляет что имеет на выходе и что имеет на входе и при валидации шаблона просто происходит проверка сопоставимости типов.
BEMJSON про струтуру блока, за оформление отвечает старый добрый CSS блока, не нужно смешивать структуру и оформление — это как раз хорошее, что есть в HTML+CSS. Или я вас не так понял?
Ну вот я считаю что если мы уже начали говорить не про html, а про блоки, то можно идти дальше по пути декларации. Чаще всего в современной вёрстке когда вы читаете css без html, вы ничего не понимаете о внешнем виде, ровно также как и чтение структуры вам ничего не даёт кроме структуры, совершенно не несёт какой-то информации зачем вам именно такая структура. Вы эти коды читаете одновременно, так почему бы и не записать их в одном месте? Одна логическая мысль должна находиться в одном месте, но кроме того если она и находится в разных местах, то должна происходить валидация имён классов в css, программа не должна позволять вам собрать проект, если в css описан элемент, которого нет в BEMHTML.
Позволю себе пофантазировать как бы я хотел видеть декларацию простого блока с иконкой и небольшими декорациями:
%user-small
style:
relative
size 256x64
inline-block
padding 0 0 0 64px
$icon
style:
bg-image 'user.png'
absolute-position 5px 5px 0 0
size 32x32
$name
style:
inline-block
font 14pt/32px
&content
Как бы это выглядело на BEM
{
block: 'b-user-small'
content: [
{
elem: 'icon'
},
{
elem: 'name'
content: this.ctx.content
}
]
}
.b-user-small
{
position: relative;
height: 64px;
width: 256px;
display: inline-block;
padding: 0 0 0 64px;
}
.b-user-small__icon
{
background: url('user.png');
position: absolute;
left: 5px;
top: 5px;
height: 32px;
width: 32px;
}
.b-user-small__name
{
display: inline-block;
font-size: 14pt;
line-height: 32px;
}
Из плюсов: не нужно чистить css, удалил элемент — удалил стиль. Не нужно постоянно переводить взгляд с одного контекста на другой. Описывая блочную модель стилями, вы сразу видите структуру. Как бесплатный бонус — не нужно перпечатывать классы элементов и не нужно проверять опечатки.
А еще подобная схема лишит возможности повкладывать одни классы в другие, что положительно скажется на новичках на проекте, приучит делать модификаторы, упростит ревью кода.
Я вот люблю сидеть за 12 дюймовым ноутбуком и мне нравится когда код компактен.
P.S.: пока писал коммент почти заново вдохновился вернуться к разработке. :)
А все началось с того, что Mirantus написал руководство по верстке html странички с низким порогом вхождения.
1. Строим дачный дом своими руками.
Берем доски, гвозди...
2. Большие сооружения делают железобетонными, значит так лучше.
Конечно не плохо бы освоить специальную технику, не вручную же месить бетон...
3. Есть же новые технологии, стройка должна быть увлекательной.
И так я расскажу как легко сделать дом из нанотрубок и графена...
4. А ты написал свою статью, о том, что ты думаешь о стройке?
1. Строим дачный дом своими руками.
Берем доски, гвозди...
2. Большие сооружения делают железобетонными, значит так лучше.
Конечно не плохо бы освоить специальную технику, не вручную же месить бетон...
3. Есть же новые технологии, стройка должна быть увлекательной.
И так я расскажу как легко сделать дом из нанотрубок и графена...
4. А ты написал свою статью, о том, что ты думаешь о стройке?
Выглядят все эти проблемы, имхо, одинаково — синдром «только что узнал».
Я ничего не имею против БЭМ, какими-то частями методологии старательно пользуюсь сам (например, только селекторы классов), но есть несколько вещей в БЭМ, которые меня заставили от него отвернуться, до тех пор пока кто-то не поменяет что-то в этой идеологии.
1. Сильная связность с каким-то стеком технологий. Можно сколько угодно кричать о том, что это просто методология, но эта методология вовсе не нова; модульность? инкапсулияция? Да причем тут БЭМ вообще? БЭМ — это куча тулзов от яндекса и энтузиастов, а не методология, все остальное придумано не ими, жило и цвело еще до появления этой аббревиатуры.
2. Невозможность покрытия модульными тестами. Честно, я бы рад, наверное, пользовать все это добро для своих проектов, но как для этого тесты писать? А если хочется еще эти тесты как-то с TeamCity связать? Один раз попробовал, лоб разбил, второй раз попробовал — да ну нафиг. Не БЭМом единым, я вполне запросто нативными средствами пишу хороший, модульный, реюзабельный JavaScript.
3. Интеграционные тесты? Окей, понятно уже.
Когда я лет пять назад впервые познакомился с jQuery, я всюду пихал ее, даже где это было не нужно, создавало боттлнеки и делало код нечитаемей. Мне жутко нравились селекторы, и я использовал их по максимуму, не особо задумываясь — а нафига?
Когда я узнал про Generic в C#, я стал пилить такие эпичные портянки с обобщенными интерфейсами, классами, методами, аттрибутами, что теперь уже даже страшно немного.
Ну ладно, когда-нибудь и любители забить гвоздь интернет-магазина на пару тысяч строк кода костылем для огромного проекта на миллионы строк словят своего северного зверька. Осознают, что серебряной пули нет и перестанут противопостовлять верстку руками мегаавтоматизированному сборщику.
Я ничего не имею против БЭМ, какими-то частями методологии старательно пользуюсь сам (например, только селекторы классов), но есть несколько вещей в БЭМ, которые меня заставили от него отвернуться, до тех пор пока кто-то не поменяет что-то в этой идеологии.
1. Сильная связность с каким-то стеком технологий. Можно сколько угодно кричать о том, что это просто методология, но эта методология вовсе не нова; модульность? инкапсулияция? Да причем тут БЭМ вообще? БЭМ — это куча тулзов от яндекса и энтузиастов, а не методология, все остальное придумано не ими, жило и цвело еще до появления этой аббревиатуры.
2. Невозможность покрытия модульными тестами. Честно, я бы рад, наверное, пользовать все это добро для своих проектов, но как для этого тесты писать? А если хочется еще эти тесты как-то с TeamCity связать? Один раз попробовал, лоб разбил, второй раз попробовал — да ну нафиг. Не БЭМом единым, я вполне запросто нативными средствами пишу хороший, модульный, реюзабельный JavaScript.
3. Интеграционные тесты? Окей, понятно уже.
Когда я лет пять назад впервые познакомился с jQuery, я всюду пихал ее, даже где это было не нужно, создавало боттлнеки и делало код нечитаемей. Мне жутко нравились селекторы, и я использовал их по максимуму, не особо задумываясь — а нафига?
Когда я узнал про Generic в C#, я стал пилить такие эпичные портянки с обобщенными интерфейсами, классами, методами, аттрибутами, что теперь уже даже страшно немного.
Ну ладно, когда-нибудь и любители забить гвоздь интернет-магазина на пару тысяч строк кода костылем для огромного проекта на миллионы строк словят своего северного зверька. Осознают, что серебряной пули нет и перестанут противопостовлять верстку руками мегаавтоматизированному сборщику.
1. кроме модульности и инкапсуляции как таковой в БЭМ есть важная методологическая составляющая про «многоязычие», т.е. что один блок реализуется в разных технологиях, т.о. получается построить обобщённые термины и для CSS, и для JS, и для любых других «технологий» (например, документация и тесты)
2. почему невозможно покрыть модульными тестами? как раз наоборот, «технология» описания тестов ложится рядом с описанием блока в CSS/JS/HTML — вот, например, модульные тесты в библиотеке bem-core: github.com/bem/bem-core/blob/v1/common.blocks/i-bem/i-bem.test.js, github.com/bem/bem-core/blob/v1/common.blocks/events/events.test.js — причём с таким подходом мы используем разные системы тестирования, от обычных модульных JS-тестов, до сравнения скриншотов
3. интеграционные тесты делаются похожим образом, только они пишутся как тесты для составных блоков (блоков, использующих внутри себя другие блоки)
2. почему невозможно покрыть модульными тестами? как раз наоборот, «технология» описания тестов ложится рядом с описанием блока в CSS/JS/HTML — вот, например, модульные тесты в библиотеке bem-core: github.com/bem/bem-core/blob/v1/common.blocks/i-bem/i-bem.test.js, github.com/bem/bem-core/blob/v1/common.blocks/events/events.test.js — причём с таким подходом мы используем разные системы тестирования, от обычных модульных JS-тестов, до сравнения скриншотов
3. интеграционные тесты делаются похожим образом, только они пишутся как тесты для составных блоков (блоков, использующих внутри себя другие блоки)
1. Я вот всегда воспринимал стек HTML+CSS+JS как некую верстальщическую MVC: моделью был HTML, вьюхой CSS, контроллером (в некотором роде) JS. Идея отказаться в CSS от всех селекторов, окромя классов, показалась мне очень здравой и не столько из-за быстродействия, сколько из-за того, что это отвязывает «модель» от «вьюхи».
В БЭМе роль модели ложится на стороннюю сущность, а стек HTML+CSS+JS (и прочие) является вьюхой.
Это у меня сейчас были мысли вслух, прошу прощения. Вообще, есть что переосмыслить, но, кажется, все равно все упрется в религию — кому как нравится.
2, 3. Беру свои слова назад, я заблуждался.
Спасибо большое за ваш комментарий, очень информативен и бесстрастен.
В БЭМе роль модели ложится на стороннюю сущность, а стек HTML+CSS+JS (и прочие) является вьюхой.
Это у меня сейчас были мысли вслух, прошу прощения. Вообще, есть что переосмыслить, но, кажется, все равно все упрется в религию — кому как нравится.
2, 3. Беру свои слова назад, я заблуждался.
Спасибо большое за ваш комментарий, очень информативен и бесстрастен.
Мне кажется, проблема с БЭМом возникает у программистов, вынужденных верстать. Верстают по-прежнему, но с новым именованием классов, не понимая специфики.
С точки зрения программиста то, что нельзя повторно использовать – говнокод.
SASS, LESS — это понятно и хорошо, а БЭМ – ммм… чото версталы придумали.
Фреймворк, чтобы из ограниченного количества классов собирать новые блоки — понятно и хорошо.
А индивидуальные, уникальные груды независимых блоков? ммм…
С точки зрения программиста то, что нельзя повторно использовать – говнокод.
SASS, LESS — это понятно и хорошо, а БЭМ – ммм… чото версталы придумали.
Фреймворк, чтобы из ограниченного количества классов собирать новые блоки — понятно и хорошо.
А индивидуальные, уникальные груды независимых блоков? ммм…
По-моему, проблема всех бэмеров и семантистов в том, что одни говорят, что надо все делать на БЭМе, а другие — только без БЭМа. Мне неудобно делать все на БЭМе (особенно читать_и__писать-длинные-классы), но сам принцип независимых от верстки классов можно без боли применять в годной семантичной верстке и я не вижу смысла не делать этого.
К тому же, в больших командах всегда составлялись правила хорошего тона для верстальщиков и программистов — просто теперь ленятся, а использовать всем поголовно БЭМ — это и есть «решение».
К тому же, в больших командах всегда составлялись правила хорошего тона для верстальщиков и программистов — просто теперь ленятся, а использовать всем поголовно БЭМ — это и есть «решение».
Основная проблема БЭМа, конечно, в самих бэмерах — они всех считают необходимым научить «как правильно», но сами никогда не готовы признавать нестыковки идеологии и применения на конкретных проектах, сливая все на непонимание окружающих. Думаю, что почти каждой команде, где уже налажена работа, знакома ситуация когда появляется бэмер и начинает слишком навязчиво использовать свои методы вразрез с теми, что уже приняты остальными. И вовсе не потому, что остальные дураки. И вовсе не потому, что дурак бэмер. Просто последние слишком категоричны и даже, возможно, немного слепы из-за этого.
Когда БЭМер приходит на проект с мусорными конвенциями, у него появляется недоумение, когда ему дают «простую задачку» поменять отступ иконочки от заголовка, а на самом деле ему приходится отгрепать весь проект на вхождение такого же класса, чтоб в другом месте ничего не отвалилось, а само название класса в свою очередь часто не говорит где искать описание стилей, от чего они наследуются/каскадируются. А в блочной иерархии, он сразу знает в каком файле что поменять и на какие элементы интерфейса эти изменения повлияют.
Основная проблема ярых противников БЭМа в том, что они сами нигде не декларируют, не документируют свои соглашения по коду, не расписывают на примерах, не делают тестовые страницы с отдельными функциональностями, а сразу пишут код на живой странице с живим сервером и не понимают зачем писать отчуждаемый код.
Никто из БЭМеров же не против перейти на другие соглашения, если они будут документированы, аргументированы и покроют все кейсы. БЭМ дисциплинирует, а не промывает мозги. Это просто нежелание работать в бардаке.
Основная проблема ярых противников БЭМа в том, что они сами нигде не декларируют, не документируют свои соглашения по коду, не расписывают на примерах, не делают тестовые страницы с отдельными функциональностями, а сразу пишут код на живой странице с живим сервером и не понимают зачем писать отчуждаемый код.
Никто из БЭМеров же не против перейти на другие соглашения, если они будут документированы, аргументированы и покроют все кейсы. БЭМ дисциплинирует, а не промывает мозги. Это просто нежелание работать в бардаке.
Не расписывайтесь за всех БЭМеров, имел дело с одним. Ему не понравилось, что все статические страницы (до кодинга тогда еще дело не дошло) собирались из отдельных паршиалов примерно так:
Sass тоже собирался из инклудов и состоял из компасовского резета, отдельной папочки partials под каждый отдельный блок-паршиал с соответствием именования (и да, там были классы-неймспейсы), папочки elements под общие элементы ui kit-а — инпуты, кнопочки и так далее, плюс отдельная папочка под миксины.
До истерики почти не понравилось.
<div class="some-container" include="blocks/articles"/>
Sass тоже собирался из инклудов и состоял из компасовского резета, отдельной папочки partials под каждый отдельный блок-паршиал с соответствием именования (и да, там были классы-неймспейсы), папочки elements под общие элементы ui kit-а — инпуты, кнопочки и так далее, плюс отдельная папочка под миксины.
До истерики почти не понравилось.
Странный БЭМер, у всех продвинутых БЭМеров именно по отдельным кусочкам и разложено всё.
но тут же не i-bem! не bemhtml! не bemjson! нет префиксов для инкапсуляции!
аргументы были примерно такие. И, к сожалению, многие БЭМеры именно такие, судя по комментариям — их не волнует то, что за них делается инкапсуляция, их не волнует, зачем, что и как, качество кода по-прежнему оставляет желать лучшего, но зато «все по гайдам». Серьезно, пройдитесь по ссылкам в последних постах по БЭМ и посмотрите на то, как аккуратно распределен по папочкам говнокод и говностили у некоторых (срач разводить не хочу, честно, поэтому ни в кого пальцем не тыкаю в постах).
аргументы были примерно такие. И, к сожалению, многие БЭМеры именно такие, судя по комментариям — их не волнует то, что за них делается инкапсуляция, их не волнует, зачем, что и как, качество кода по-прежнему оставляет желать лучшего, но зато «все по гайдам». Серьезно, пройдитесь по ссылкам в последних постах по БЭМ и посмотрите на то, как аккуратно распределен по папочкам говнокод и говностили у некоторых (срач разводить не хочу, честно, поэтому ни в кого пальцем не тыкаю в постах).
Основная проблема ярых противников БЭМа в том, что они сами нигде не декларируют, не документируют свои соглашения по коду, не расписывают на примерах, не делают тестовые страницы с отдельными функциональностями.
А я как раз написал выше, что в больших командах всегда были свои правила и соглашения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В чем проблема «проблемы БЭМ'а»?