Комментарии 100
Как верстали 10 лет назад
…
Пример
#foot div div div div...
Слишком утрировать не надо. «Так верстали только мудаки», разве что.
НЛО прилетело и опубликовало эту надпись здесь
Концепции очень разумные. Сам долго плевался от синтаксиса и этих двойных подчеркиваний и всего такого, но в итоге сдался, потому что это чертовски удобно, вариантов используемого синтаксиса не так уж много (не любитель camelCase в CSS, поэтому остановился на BEM с синтаксисом Гарри Робертса, по примеру Гугла и Salesforce), а преимущества на дистанции — очень солидные.
Все равно многие вещи остаются не очень очевидными, конечно, это не решает всех проблем именования в CSS, со временем все равно накапливается технический долг в проектах по части CSS и часто присутствуют проблемы интеграции с готовыми решениями/фреймворками вроде TWBS, Foundation, Semantic, итд, но, думаю, всему свое время. Может и BEM предложит что-то еще.
Все равно многие вещи остаются не очень очевидными, конечно, это не решает всех проблем именования в CSS, со временем все равно накапливается технический долг в проектах по части CSS и часто присутствуют проблемы интеграции с готовыми решениями/фреймворками вроде TWBS, Foundation, Semantic, итд, но, думаю, всему свое время. Может и BEM предложит что-то еще.
НЛО прилетело и опубликовало эту надпись здесь
Пишите ещё неконструктивные комментарии.
НЛО прилетело и опубликовало эту надпись здесь
Комментарии типа «вам тут всем требуется толерантное отношение, а я стою весь в белом, красивый, д'Артанян» сильно раздражают. Минусы точно не за иное мнение, а за то, что вам в жизни не повезло.
Не согласен — обоснуй. А если есть просто желание взписнуть безадресный и бессмысленный поток эмоций во вселенную, то чему вы удивляетесь? Я бы и сам влепил минусок-другой.
Не согласен — обоснуй. А если есть просто желание взписнуть безадресный и бессмысленный поток эмоций во вселенную, то чему вы удивляетесь? Я бы и сам влепил минусок-другой.
НЛО прилетело и опубликовало эту надпись здесь
Уважаемый. «Конструкция, заложенная в БЭМ недеструктивна» — так может писать только тот, кто обладает общепринятым авторитетом. Скажем, я поверю на слово многому из того что скажет [вставьте сюда *уважаемого* вами человека]. Человек из ниоткуда, да ещё и с минусовой кармой изъявлять истины, конечно, может. Но это выглядит И смешно И глупо, простите.
Что бы человека кто-то слушал надо либо заслужить авторитет заранее, либо чётко обосновывать свои слова. Вот я могу написать: «вавилон это не город». Будете спорить или примете на веру?
Ещё раз. Летящие Вам минусы никакого отношения к БЭМ вообще не имеют.
Что бы человека кто-то слушал надо либо заслужить авторитет заранее, либо чётко обосновывать свои слова. Вот я могу написать: «вавилон это не город». Будете спорить или примете на веру?
Ещё раз. Летящие Вам минусы никакого отношения к БЭМ вообще не имеют.
НЛО прилетело и опубликовало эту надпись здесь
Хабр — это такое место, где комментарии должны обладать ценностью. Комментарии, не соответствующие этому критерию, атакуются иммунной системой. Неаргументированное мнение никому не известного человека ценностью не обладает.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Компетентность в вопросе — это когда человек может убедительно аргументировать свое мнение. А вы для высказывания «За идею реализацию БЭМ двойка с минусом. Жирная.» — никаких аргументов не привели.
Мне понравилась вот эта ссылка http://maximilyahov.ru/blog/all/tri-zakona-kritiki/ я думаю, это помогло бы убрать недопонимание между вами и минусующими. Точнее минусов бы не было, зато была бы интересная беседа, от которой выиграли бы все.
У горе-архитекторов БЭМ есть вакансии в Мск и Симферополе. Будем рады обсудить потенциальную помощь. Деньги есть ;)
Очевидно единственный, но серьезный недостаток БЭМ, это то, что он убивают саму идею каскадности превращая css в ss.
Причем БЭМ не исправляет недостатки реализации каскадности изначально заложенные в css, а именно пытается устранить ее влияние полностью.
Не согласны?
Причем БЭМ не исправляет недостатки реализации каскадности изначально заложенные в css, а именно пытается устранить ее влияние полностью.
Не согласны?
НЛО прилетело и опубликовало эту надпись здесь
Ну возможно я перегибаю палку, когда пишу «полностью» и правильно бы было написать «почти полностью», но в целом же я прав? Вот смотрите — есть у меня страничка для мальчиков где все элементы управления, кнопочки и т.п. синенькие, а есть для девочек где они розовенькие.
Переношу я блок с кнопкой на страницу для девочек и получаю… синенькую кнопочку. С чего бы это? А мне надо поменять модификатор.
Ну вы поняли.
Смысл в том что я теряю целостность стиля и вместо того чтобы работать со страницей работаю с кучей маленьких страниц.
Хуже только атомарная верстка с этой точки зрения.
(*не имею ничего против БЭМ — система вполне имеет право на жизнь, но не стоит говорить что она лечит web — нет, только прячет некоторые симптомы тяжело больного)
Переношу я блок с кнопкой на страницу для девочек и получаю… синенькую кнопочку. С чего бы это? А мне надо поменять модификатор.
Ну вы поняли.
Смысл в том что я теряю целостность стиля и вместо того чтобы работать со страницей работаю с кучей маленьких страниц.
Хуже только атомарная верстка с этой точки зрения.
(*не имею ничего против БЭМ — система вполне имеет право на жизнь, но не стоит говорить что она лечит web — нет, только прячет некоторые симптомы тяжело больного)
Именно.
Вот только это не недостаток, а особенность. Каскадность в больших проектах приносит больше проблем, чем пользы.
Реально она нужна только для написания стилей к плохой чужой вёрстке, например — морд на чужие сайты.
>Переношу я блок с кнопкой на страницу для девочек и получаю… синенькую кнопочку. С чего бы это? А мне надо поменять модификатор.
А почему у вас в этом случае модификатор висит на кнопочке, а не на
Вот только это не недостаток, а особенность. Каскадность в больших проектах приносит больше проблем, чем пользы.
Реально она нужна только для написания стилей к плохой чужой вёрстке, например — морд на чужие сайты.
>Переношу я блок с кнопкой на страницу для девочек и получаю… синенькую кнопочку. С чего бы это? А мне надо поменять модификатор.
А почему у вас в этом случае модификатор висит на кнопочке, а не на
body?
Думаю, что не единственный. Отказ от каскадности это одно из следствий еще более серьезной проблемы — сопровождаемость верстки в HTML. Если смотреть на сапровождаемость верстки через HTML, CSS со своим разнообразием всегда будет проблемой для БЭМ.
Ещё стоит помнить, что термин «каскадный» из названия технологии, это не про составные селекторы «div .class», а про каскадное применение правил из разных деклараций. БЭМ эту идею не убивает, а использует на полную катушку. Использования селекторов по БЭМ неймингу, позволяет избегать неоправданного повышения спецефичности селектора, при сохранении изолированности. Таким образом, достигается более предсказуемое применение стилей.
авторитетные ссылки по теме:
* каскад www.w3.org/TR/2009/CR-CSS2-20090908/cascade.html#cascade
* специфичность developer.mozilla.org/ru/docs/Web/CSS/Specificity
* каскад www.w3.org/TR/2009/CR-CSS2-20090908/cascade.html#cascade
* специфичность developer.mozilla.org/ru/docs/Web/CSS/Specificity
С завидной регулярностью Я публикует заметки в духе «Как уверовать в БЭМ». Никто не покупает или в чем причина?
НЛО прилетело и опубликовало эту надпись здесь
Да ладно, БЭМ однозначно взлетел, причем не только в России, но и в мире — а это редко кому удается.
Распространённее технология → больше знающих её людей → меньше времени на обучение новых сотрудников.
Покупают. Material Design Lite например
По-моему, где-то уже спрашивал про это, но внятного ответа не получил:
БЭМ — это только про фронтенд, или есть методики/примеры, как по БЭМу организовать взаимодействие с бэкендом, используя разные серверные технологии? Например, можно ли как-то энкапсулировать логику, соответствующую [сложным] блокам, в серверном коде, ajax API и т.п.?
БЭМ — это только про фронтенд, или есть методики/примеры, как по БЭМу организовать взаимодействие с бэкендом, используя разные серверные технологии? Например, можно ли как-то энкапсулировать логику, соответствующую [сложным] блокам, в серверном коде, ajax API и т.п.?
Возможно, поможет: Сервер-сайд в БЭМ-терминах (Node.js).
Видел интересный кейс применения БЭМ. Все было красиво сверстано, блоки в папочках, судя по всему какие-то тулы для БЭМа использовались и т.д. Вот передали нам штук 50 так сверстанных макетов, выглядит все красиво, но при попытки собрать их в SPA начался ад и содомия, все начало расползаться ломаться и взрываться. Видимо формального раскладывания CSS по папочкам — не достаточно для создания качественной верстки.
Не пойму — в интернете мало инфы на эту тему?
Смысл каждый раз расписывать значение каждой буквы, что такое Б, что такое Э, что такое М?!
Кому нужно, и считает это клёвым — уже юзает, либо просто в курсе этого, кому не нужно — обходит стороной.
Вопрос — чего вы это всем навязываете постоянными постами?
Смысл каждый раз расписывать значение каждой буквы, что такое Б, что такое Э, что такое М?!
Кому нужно, и считает это клёвым — уже юзает, либо просто в курсе этого, кому не нужно — обходит стороной.
Вопрос — чего вы это всем навязываете постоянными постами?
НЛО прилетело и опубликовало эту надпись здесь
Вот есть у меня такой код:
Как правильно переписать этот html с точки зрения BEM?
Тут как бы .dob-part не должен существовать без .dob-field, но с другой стороны есть стили вроде .dob-field .dob-part input.
Получается нужны классы вроде .dob-field__dob-part__textInput, но тогда это не BEM, а BEEM, какой-то.
<div class="dob-field">
<div class="dob-part">
<label>Day</label>
<input type="text" name="day"/>
</div>
<div class="dob-part">
<label>Month</label>
<input type="text" name="month"/>
</div>
<div class="year">
<label>Year</label>
<input type="text" name="year"/>
</div>
</div>
Как правильно переписать этот html с точки зрения BEM?
Тут как бы .dob-part не должен существовать без .dob-field, но с другой стороны есть стили вроде .dob-field .dob-part input.
Получается нужны классы вроде .dob-field__dob-part__textInput, но тогда это не BEM, а BEEM, какой-то.
НЛО прилетело и опубликовало эту надпись здесь
Предложенная banzalik разметка в BEMJSON:
Применяя BEMHTML можно сократить:
Демонстрация bem-core + BEMHTML jsfiddle.net/ilyar/x1bfu5zh
{
"block": "date-form",
"content": [
{
"elem": "item",
"elemMods": { "type": "day" },
"content": [
{ "elem": "label", "content": "Day" },
{ "elem": "input", "tag": "input", "attrs": { "type": "text", "name": "day" } }
]
},
{
"elem": "item",
"elemMods": { "type": "month" },
"content": [
{ "elem": "label", "content": "Month" },
{ "elem": "input", "tag": "input", "attrs": { "type": "text", "name": "month" } }
]
},
{
"elem": "item",
"elemMods": { "type": "year" },
"content": [
{ "elem": "label", "content": "Year" },
{ "elem": "input", "tag": "input", "attrs": { "type": "text", "name": "year" } }
]
}
]
}
Применяя BEMHTML можно сократить:
{
"block": "date-form",
"content": [
{
"elem": "item",
"elemMods": { "type": "day" },
"content": "Day"
},
{
"elem": "item",
"elemMods": { "type": "month" },
"content": "Month"
},
{
"elem": "item",
"elemMods": { "type": "year" },
"content": "Year"
}
]
}
Демонстрация bem-core + BEMHTML jsfiddle.net/ilyar/x1bfu5zh
Если интересно посмотреть на БЭМ + Sailsjs (как Rails только на javascript), у меня есть
Почему бы просто не использовать CSSModules?
CSSModules про скоупинг в CSS, а БЭМ — про компонентный подход. Как Web Components, но от практикующих разработчиков.
CSSModules можно использовать вместе с БЭМ, другое дело, что «классический» БЭМ тоже более-менее решает задачу со скоупингом :)
CSSModules можно использовать вместе с БЭМ, другое дело, что «классический» БЭМ тоже более-менее решает задачу со скоупингом :)
НЛО прилетело и опубликовало эту надпись здесь
id обязан быть уникальным, и отсюда вытекают два неприятных свойства:
1) это очень трудно гарантировать
2) если использовать id для идентификации, то на странице может быть только один инстанс такого типа — а это может «выстреливать» в самые неожиданные моменты, когда вдруг понадобится второй
class же во всём может заменить id и при этом не обладает такими недостатками
раньше (лет 10 назад) у id было преимущество про скорость (браузеры не сильно оптимизировали DOM-дерево и не строили никаких кешей по class), но со временем эта разница существенно сгладилась
1) это очень трудно гарантировать
2) если использовать id для идентификации, то на странице может быть только один инстанс такого типа — а это может «выстреливать» в самые неожиданные моменты, когда вдруг понадобится второй
class же во всём может заменить id и при этом не обладает такими недостатками
раньше (лет 10 назад) у id было преимущество про скорость (браузеры не сильно оптимизировали DOM-дерево и не строили никаких кешей по class), но со временем эта разница существенно сгладилась
НЛО прилетело и опубликовало эту надпись здесь
От именованных объектов никто не отказывается. Просто для них не пишется специфических стилей.
А в JS — по прежнему работаем со всеми способами идентификации объекта.
А в JS — по прежнему работаем со всеми способами идентификации объекта.
НЛО прилетело и опубликовало эту надпись здесь
Тогда я не понял, что Вы называете неименованными объектами, и как предлагаете писать стили для них.
НЛО прилетело и опубликовало эту надпись здесь
«Изнутри» — это откуда? Приведите пример кода, в котором требуется достучаться до ноды изнутри.
С чего это нода именованный объект? Нода — элемент коллекции, иерархии и т. п., из которых её можно выбрать по разным признакам (селекторам). Имя — необязательный, а иногда и невозможный (текстовая нода, например) атрибут ноды, лишь один из признаков ноды, по которой её можно выбрать из множества остальных нод.
Или вы под нодой имеете в виду только ноду типа HTMLElement, а под её именем — имя этого элемента?
Или вы под нодой имеете в виду только ноду типа HTMLElement, а под её именем — имя этого элемента?
честно говоря я почитал ваш подтред с Zenitchik, но не смог понять, что Вы называете неименованными объектами и связано ли это с id
случайно речь не про
случайно речь не про
<div class="my-block" data-bem='{ "my-block" : {} }'>...
чем оно отличается от того же smacss.com?
почему стоит использовать БУЭМ?
Был же OOCSS и др до БЭМ, вы по сути ничего не придумали, а просто другой нейминг сделали.
почему стоит использовать БУЭМ?
Был же OOCSS и др до БЭМ, вы по сути ничего не придумали, а просто другой нейминг сделали.
БЭМ — это не только про CSS. В чем отличие БЭМ от OOCSS, AMCSS, SMACSS, SUITCSS можно почитать на нашем сайте.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
БЭМ не предполагает никаких супер-блоков, блоки можно без ограничейний вкладывать друг в друга.
Про обертки есть пост на форуме на bem.info: https://ru.bem.info/forum/656/
Про обертки есть пост на форуме на bem.info: https://ru.bem.info/forum/656/
НЛО прилетело и опубликовало эту надпись здесь
Блок — независимый компонент. На него не должны влиять CSS-правила, созданные для всей страницы. Это нарушает независимость блоков и затрудняет их повторное использование.
Подробнее и с примером можно почитать тут.
Подробнее и с примером можно почитать тут.
Банально из-за экономии ресурсов. По методологии блок определяет сам всё для себя, в том числе и те стили, которые сброшены (вернее определены) глобально. А если всё определяется блоком, то зачем глобальный сброс?
Подскажите, где можно почитать про то, как переопределить все правила, ничего не забыв? Наверняка же кто-то уже перечислил весь список правил, которые могут быть унаследованы сверху.
НЛО прилетело и опубликовало эту надпись здесь
Есть наследование свойств, а есть каскад правил. Со свойствами как раз проблем обычно нет — открываешь описание элемента и переопределяешь все свойства, помеченные как наследуемые от родительского (общего списка нет формально, есть разной степени актуальности и полноты агрегаты). Проблемы обычно с правилами по умолчанию в браузерах, как минимум с теми, для которых в спецификации явно указано, что определяются разработчиком клиента, а не имеют стандартное значение.
Варианты решения:
1. определять явно все свойства, которые есть у элемента, как собственные, так и наследуемые, по спецификации, не забыв про вендорские
2. проводить анализ значений свойств по умолчанию по спецификации и задавать те, которые отданы на откуп вендорам
3. проводить анализ значений свойств по умолчанию в целевых агентах и задавать те, которые де-факто отличаются
4. совмещать 2 и 3
5. задавать значения по мере выявления конкретных багов, неожиданного поведения во всех или отдельных агентах
В общем случае, стремление «ничего не забыть» похвально, но недостижимо, поскольку новые свойства и их реализации в агентах появляются постоянно, поэтому разумно использовать переопределение только очевидных свойств, либо не имеющих стандартного значения по умолчанию, либо широко известных как имеющих разные реализации, не смотря на спецификацию, а дальше решать проблемы по мере поступления.
Варианты решения:
1. определять явно все свойства, которые есть у элемента, как собственные, так и наследуемые, по спецификации, не забыв про вендорские
2. проводить анализ значений свойств по умолчанию по спецификации и задавать те, которые отданы на откуп вендорам
3. проводить анализ значений свойств по умолчанию в целевых агентах и задавать те, которые де-факто отличаются
4. совмещать 2 и 3
5. задавать значения по мере выявления конкретных багов, неожиданного поведения во всех или отдельных агентах
В общем случае, стремление «ничего не забыть» похвально, но недостижимо, поскольку новые свойства и их реализации в агентах появляются постоянно, поэтому разумно использовать переопределение только очевидных свойств, либо не имеющих стандартного значения по умолчанию, либо широко известных как имеющих разные реализации, не смотря на спецификацию, а дальше решать проблемы по мере поступления.
Просто оставлю это тут…
Мы долго экспериментировали с префиксами в именах, но в итоге отказались от них.
Насчет префиксов — они необходимы. Бывает так, что блоки (повторно используемые компоненты) требуется встроить в другие приложения и экосистемы. Причем заранее, только начиная разработку и выбирая методологию, вы не можете быть уверены в том, что компоненты не понадобятся в еще одном приложении, которое появится через пару лет. А еще если это приложение само использовало методологию БЭМ, и там также есть «header», «footer» и «btn», только с другой версткой. Не будете же вы переделывать весь UI Kit ради этого приложения.
Хорошие примеры использования префиксов — Material Design Lite, Atlassian UI (это библиотека компонентов от Atlassian, авторов JIRA, Bitbucket и др.). Первые все компоненты именуют с «mdl-», вторые с «aui-» — на трехбуквенном префиксе уже гораздо меньше вероятность пересечься. Разве что ваша компания называется More Digital Licences или Awesome United Inventions.
Плохой пример отказа от префиксов — Bootstrap со своими «row», «col», «form», «btn» и подобными «блоками». Как будто на странице не может быть других кнопок, кроме бутстраповских. Если следовать принципу отказа от префиксов в своем коде, то рано или поздно появится какой-нибудь блок «btn», которые впоследствии законфликтует с бутстрапом будучи вставленным на бутстраповскую страницу.
Посередине — jQuery UI. Они выбрали «ui-», но данный префикс слишком абстрактный. Как будто больше пользовательские интерфейсы никто не разрабатывает.
Говоря о популярности БЭМ, и что сам ГУГЛ его использует в mdl,
надо всё-таки по-честному разделять подход к наименованию классов, который и правда хорош и распространен (с небольшими изменениями у того же Гугл), и инструменты типа bem-tools, которые мягко говоря медленные ) и никакой ГУГЛ их использовать никогда не будет.
Да, есть enb, но не странно ли, что один разработчик в свободное от работы время, «на коленке» написал сборщик,
работающий в разы быстрее bem-tools, непонятно, чем же тогда занималась вся команда БЭМ? Наверное писала статьи на хабр… )
Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
И это совсем не обнадеживает.
Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-ситаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller
Как бы там ни было, БЭМ прошел огромный путь, имеет хорошую поддержку и стоит того, чтобы как минимум его попробовать и иметь о нем свое мнение, а не просто хаять, как делают здесь некоторые комментаторы.
И я желаю разработчикам успехов в его совершенствовании.
PS:
В части «с чего всё начиналось» можно было рассказать и о «y5.js» который был до лего-бэма
и был благополучно похоронен на основании тех же доводов о «пороге вхождения»
надо всё-таки по-честному разделять подход к наименованию классов, который и правда хорош и распространен (с небольшими изменениями у того же Гугл), и инструменты типа bem-tools, которые мягко говоря медленные ) и никакой ГУГЛ их использовать никогда не будет.
Да, есть enb, но не странно ли, что один разработчик в свободное от работы время, «на коленке» написал сборщик,
работающий в разы быстрее bem-tools, непонятно, чем же тогда занималась вся команда БЭМ? Наверное писала статьи на хабр… )
Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
И это совсем не обнадеживает.
Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-ситаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller
Как бы там ни было, БЭМ прошел огромный путь, имеет хорошую поддержку и стоит того, чтобы как минимум его попробовать и иметь о нем свое мнение, а не просто хаять, как делают здесь некоторые комментаторы.
И я желаю разработчикам успехов в его совершенствовании.
PS:
В части «с чего всё начиналось» можно было рассказать и о «y5.js» который был до лего-бэма
и был благополучно похоронен на основании тех же доводов о «пороге вхождения»
кроме того, про что написал tadatuta habrahabr.ru/company/yandex/blog/276035/#comment_8767005 (жаль у меня нет кармы ставить плюсики каментам), не могу молчать про похороны y5, т.к. «из первых рук» знаю про ситуацию — основная причина была в закрытости кода и невозможности подключить к сообществу внешних людей
Сережа, где же твоя карма? ) Я присутствовал на разговоре Бобука, кажется с Надей (уже не помню точно) Речь шла о том, что найти разработчиков со знанием jQuery сильно легче чем со знанием y5. Ну и сам помнишь, после ухода Андрея ее банально некому было развивать
настоящая карма всегда со мной ;-) а вот почему нельзя оценивать комментарии не написав ни одного поста, это пусть останется на карме разработчиков хабра
то что ты говоришь, это уже следствие — после ухода Андрея мы его вполне развивали аналогичными темпами с Лёшей и Лёней, вот только нужно было экспоненциально растить темпы (без опенсорса это практически не реально)
то что ты говоришь, это уже следствие — после ухода Андрея мы его вполне развивали аналогичными темпами с Лёшей и Лёней, вот только нужно было экспоненциально растить темпы (без опенсорса это практически не реально)
Несколько поинтов:
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.
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.
Хорошая презентация: ihorzenich.github.io/talks/2015/frontendweekend-bem
С нее хорошо втягиваться в БЭМ, там только суть без фулстека, подходит тем, кто вообще не шарит.
С нее хорошо втягиваться в БЭМ, там только суть без фулстека, подходит тем, кто вообще не шарит.
НЛО прилетело и опубликовало эту надпись здесь
На эту тему еще есть вебинар «Основы БЭМ-методология: необходимость появления, история и основные понятия», если кому-то интересно покопаться в истории.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
БЭМ-методология: с чего всё начиналось и зачем это всё нужно