company_banner

БЭМ-методология: с чего всё начиналось и зачем это всё нужно

    На Хабре уже много писали о методологии БЭМ, выросшей в Яндексе. И мы решили, что пора системно рассказать о том, откуда она появилась и что сделало БЭМ таким, каким мы его знаем. Думаем, это будет интересно не только тем, кто уже использует БЭМ, но и тем, кто считает, что эта методология не подходит для их проектов. Возможно, они увидят, что мы решали проблемы, похожие на их собственные, и найдут что-то полезное для себя.

    image

    Конечно, все началось с собственных потребностей Яндекса. Вместе с тем, как он рос, росло и количество сотрудников, которые занимаются фронтендом. Постепенно команда увеличилась настолько, что стало очевидно — без единых стандартов работать будет сложно. К тому же, мы находимся в офисах Яндекса в разных городах. Возникла идея создать общую методологию, которая поможет организовать процессы в большой команде, работающей над разными проектами. А главное то, что мы хотели не только упорядочить и ускорить разработку, но и снизить порог входа в проект для нового разработчика.

    Для чего нужна БЭМ-методология


    Какие требования мы сформулировали:
    • Разработчик должен понимать свой код (даже вернувшись к нему через год) и код любого программиста в команде БЭМ-проекта.
    • Любой блок кода может быть использован повторно: необходимо создать общую базу знаний и не писать каждый раз всё с нуля, а использовать готовые наработки.
    • Работая в одной команде, разработчики, менеджеры, дизайнеры и верстальщики должны называть одни и те же вещи одинаково. То есть говорить на одном языке.
    • Команды могут обмениваться специалистами для реализации какой-то конкретной функциональности.
    • Порог входа при переходе на новый проект должен быть снижен за счет одинаковой структуры организации всех БЭМ-проектов и одинаковых правил именования всех сущностей.


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

    История развития БЭМ


    Как верстали 10 лет назад


    Но когда все начиналось, ни о каких компонентных подходах и модульности в веб-разработке речи не шло. Все верстали сайты, складывая CSS в один файл project.css, скрипты, которых было очень мало, — в project.js, а картинки — в папку images.

    В 2005 году обычный, с точки зрения интерфейса, проект был набором статических HTML-страниц. Вот такой была типичная структура проекта того времени:

    about.html      # Для каждой страницы создавался отдельный HTML-файл
    index.html
    …
    project.css     # Стили находились в одном файле для всего проекта
    project.js      # Скрипты хранились в одном файле для всего проекта
    images/         # Картинки складывались в отдельную директорию
      yandex.png
    


    В CSS использовались id, классы и теги.

    Пример

        #foot div div div div
        {
            background-position: 54%;
            background-image: url(../i/foot-4.png);
        }
    


    Типичный CSS того времени в большинстве случаев содержал длинный каскад.

    Малейшие изменения требовали длительного рефакторинга. Свёрстанные статические HTML-страницы нарезались в шаблоны. Если HTML изменялся, все правки было необходимо переносить вручную в шаблон.

    Вёрстка в больших проектах была неуправляемой.


    Основы БЭМ-методологии


    Технологии (HTML, CSS, JavaScript), которые мы использовали, изменялись в зависимости от требований проекта, а принципы БЭМ должны были быть универсальны.

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

    Чтобы ускорить разработку, необходимо было облегчить поддержку HTML и CSS отдельных компонентов страницы, сделать код менее связанным. Для этого мы разбили страницу на части. Так появилось новое понятие — блок. Блок мог состоять из различных элементов, которые не использовались вне самого блока. Состояния и поведение блока и элемента можно было задавать с помощью модификатора.

    Это были три ключевых понятия, на которых основывалось большинство правил. Аббревиатура от трех слов Блок, Элемент и Модификатор стала названием методологии — БЭМ.

    Блок


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

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

    image

    Элемент


    Часть блока, которая не может использоваться в отрыве от него и имеет смысл только в рамках своего родителя. Элементы могут быть обязательными и опциональными.

    Работая с элементами, важно помнить правило: не рекомендуется создавать элементы элементов. Если вложить один элемент в другой, будет невозможно изменить внутреннюю структуру блока: элементы нельзя будет поменять местами, удалить или добавить без корректировки существующего кода.

    image

    Модификатор


    Свойство блока или элемента, которое меняет их внешний вид, состояние или поведение.
    Модификатор имеет имя и может иметь значение. Использование модификаторов опционально. У блока/элемента может быть несколько разных модификаторов одновременно.

    Так, например, с помощью модификатора можно изменить не только цвет меча, но и его функциональность (как показано в случае с красным мечом):

    image

    Правила именования CSS-селекторов


    Все принципы БЭМ формировались и внедрялись постепенно. Мы начали с того, что сформулировали жесткие правила именования CSS-селекторов.

    По БЭМ-методологии блоки не уникальны и их всегда можно использовать повторно, поэтому в описании CSS-правил отказались от использования id.

    Блок не должен зависеть от окружающих его блоков и сам не должен влиять на соседние блоки, поэтому в CSS отказались от:
    • тегов;
    • вложенных селекторов;
    • глобального сброса правил для всей страницы.


    Важной определяющей сущностью в именовании селекторов стал блок:
    • Полное имя элемента/модификатора формируется так, чтобы из него можно было определить принадлежность данного элемента/модификатора к конкретному блоку.
    • По имени модификатора элемента должно быть возможно определить принадлежность данного модификатора к конкретному элементу конкретного блока.


    Правила формирования имени БЭМ-сущности


    • Каждая БЭМ-сущность должна иметь свой класс.
    • CSS-свойства для блоков, элементов и модификаторов описываются только через классы.
    • Для разделения слов в именах используется дефис (-).
    • Элемент отделяется от блока двумя подчеркиваниями (__). Модификатор — одним (_).
    • Имена БЭМ-сущностей записываются с помощью цифр и латинских букв в нижнем регистре.


    Мы долго экспериментировали с префиксами в именах, но в итоге отказались от них.

    Пример

    • Имя блока — header.
    • Имя элемента блока — header__search-form — элемент search-form блока header.
    • Имя модификатора блока — header_theme_green-forest — модификатор theme в значении green-forest блока header.
    • Имя модификатора элемента — header__search-form_disabled — булев модификатор disabled элемента search-form блока header.


    HTML

    <div class="header header_theme_green-forest">...</div>
    


    CSS

    .header { color: red; }
    


    Существует ряд альтернативных схем именования. Выбор всегда остается за вами.

    Но мы рекомендуем придерживаться описанной выше схемы, так как инструменты БЭМ-платформы умеют работать именно с данным вариантом именования.

    БЭМ в HTML


    Мы хотели упорядочить HTML и в итоге пришли к тому, что больше не пишем HTML руками. Подробнее читайте в разделе про описание инструментов БЭМ.

    В HTML каждая БЭМ-сущность определяется своим классом.

    <div class="block-name">
      <div class="block-name__elem"></div>
         ...
    </div>
    


    В простейшем случае блок соответствует DOM-узлу, один к одному. Но DOM-узел и блок — это не всегда одно и то же. На одном DOM-узле может совмещаться несколько сущностей. Это называется миксом.

    С помощью миксов можно:
    • объединять поведение и стили нескольких БЭМ-сущностей без дублирования кода;
    • создавать семантически новые компоненты интерфейса на основе имеющихся блоков, элементов и модификаторов;
    • задавать позицию вложенного блока в родительском, не создавая дополнительных модификаторов. Подробнее, о том, как создавать обёртки в HTML, читайте на форуме.


    Пример

    В проекте кнопки реализованы блоком button. Необходимо поместить кнопку в форму поиска (search-form) и задать для кнопки отступы. Для этого воспользуемся миксом блока button и элемента button блока search-form:

    <div class="search-form">
      <div class="button search-form__button"></div>
    </div>
    


    Микс позволяет использовать универсальную кнопку, которая ничего не знает об отступах от границ конкретной формы. В данном случае в форме поиска есть элемент search-form__button, который знает, где ему надо находиться, и блок button, который нужно отображать.

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

    Организация файловой системы


    Нас не устраивала первоначальная структура проекта в файловой системе: в ней было сложно ориентироваться и находить нужные технологии сущностей.

    Что мы хотели получить от новой структуры:
    • Унифицированную файловую систему любого БЭМ-проекта.
    • Универсальную расширяемую структуру репозитория. При добавлении в проект дополнительной технологии заранее известно, где будут находиться новые файлы.
    • Быстрый поиск по файловой системе проекта.
    • Повторное использование кода.
    • Неограниченную возможность переноса кода всего блока из проекта в проект.


    Сначала мы попробовали разделить репозиторий проекта по технологиям:

    css/
    html/
    js/
    xml/
    xsl/
    


    Такой подход не показал кардинальных изменений. Поэтому мы вынесли общую часть кода, подходящую для всех проектов и платформ, в отдельную директорию common. Специфические реализации, необходимые только определённым проектам, складывали отдельно — в директорию service. А примеры — в директорию example.

    common/
      css/
      js/
      xml/
      xsl/
    example/
      html/
    service/
      auto/
        css/
        xml/
    


    Так мы быстрее находили нужный код для отдельных проектов. Но эта структура всё равно не отвечала всем нашим требованиям.

    Блоки первичны, технологии — вторичны


    Чтобы создать нужную нам структуру проекта и реализовать наши цели, которые мы перед собой ставили, мы вывели на передний план блоки, а не технологии.

    Блок в файловой системе полностью независим: все технологии, необходимые для его реализации, находятся в директории этого блока.

    Чего мы добились:

    Ускорения разработки
    • Блоки могут использоваться повторно.
    • Реализация блоков может быть изменена на новом уровне переопределения, не затрагивая при этом базовую функциональность и стили.
    • Блок — независимый компонент страницы и в его директории находится всё, что необходимо для корректного функционирования. Поэтому блоки легко переносить из проекта в проект, достаточно просто скопировать директорию блока.

    Ускорение рефакторинга
    • Разработчик работает c небольшими блоками кода.
    • Технологии реализации одного блока не связаны с технологиями другого.
    • Одинаковая структура репозитория позволяет быстро ориентироваться в проекте и находить нужные файлы.

    Универсальная расширяемая система
    • Появились уровни переопределения.
    • Количество технологий не ограничено. Любая новая технология реализации находится в файле конкретного блока. Так, когда мы создавали новую файловую структуру, мы не планировали писать unit-тесты на JavaScript. Но, когда появилась такая необходимость, мы знали, где разместим эти файлы в проекте.


    Технологии реализации


    Придумали новый термин — технология реализации.

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

    Для реализации блока используются различные технологии, например:
    • поведение — JavaScript, CoffeeScript;
    • внешний вид — CSS, Stylus, Sass;
    • шаблоны — Jade, Handlebars, XSL, BEMHTML, BH;
    • документация — Markdown, Wiki, XML.


    Выбор технологий реализации не ограничен, разве только требованиями вашего проекта.

    В новой организации файловой структуры каждая технология реализации представляет собой отдельный файл с соответствующим расширением. Все файлы реализации блока хранятся в директории этого блока.

    Всё в проекте перестраивается относительно этого нового принципа. Блок становится ключевым понятием БЭМ. Соответственно, изменяется и структура файловой системы.

    Правила организации файловой системы БЭМ-проекта


    • Блок — отдельная директория в файловой системе. Имя блока и его директории совпадают.
    • Реализация блока разделяется на отдельные файлы.
    • Файлы, относящиеся к блоку, всегда находятся в его директории.
    • Опциональные элементы и модификаторы выносятся в отдельные файлы.
    • Проект разделяется на уровни переопределения.


    Пример

    blocks/
      input/                     # Директория блока input
        _theme/                  # Директория опционального модификатора theme
          input_theme_forest.css # Реализация модификатора theme в значении forest в технологии CSS
        __clear/                 # Директория опционального элемента clear
          input__clear.css       # Реализация элемента clear в технологии CSS
          input__clear.png       # Реализация элемента clear в технологии PNG
        input.css                # Блок input в технологии CSS
        input.js                 # Блок input в технологии JavaScript
      button/                    # Директория блока button
        button.css
        button.js
        button.png
    


    Уровень переопределения

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

    Уровни переопределения позволяют:
    • Подключать библиотеки и обновлять их, не делая правок в коде.
    • Выделять общие части реализаций блоков на один уровень, а частные случаи (например, специфическую реализацию для отдельных сервисов) — на другой.
    • Разделять проект на платформы. Общую реализацию для всех платформ хранить на одном уровне, а платформо-специфичную — выносить на другой.
    • Избежать копирования кода и создания новых сущностей, если необходимо изменить уже существующую функциональность.


    Если сравнить уровни со слоями, то базовый слой – это исходная реализация блока, а каждый последующий слой накладывается сверху и дополняет (наследует) или изменяет базовую реализацию.

    image

    Пример

    project/           # Уровень проекта
      input/           # Измененная реализация блока input
      button/
      header/
    library-blocks/    # Уровень библиотеки
      input/           # Базовая реализация блока input
      button/
      popup/
    


    Как начать работать с БЭМ


    Как вы могли заметить, наша команда тоже начинала работу с БЭМ постепенно. Гибкость БЭМ-методологии позволяет настраивать её под ваши текущие процессы.

    Не существует универсального метода, чтобы начать применять методологию в своем проекте. Каждая конкретная команда встраивает его в процесс разработки и использует так, как ей удобно.

    Например, у вас есть проект, в котором вы хотите применить БЭМ только для вёрстки. Вы используете в проекте CSS и HTML, значит можно начать с правил именования CSS-селекторов. Это самый распространенный способ использования БЭМ-методологии. Многие команды начинают именно с него. Мы тоже с этого начинали.

    По мере внедрения новых правил возникает потребность в собственных инструментах и технологиях.

    БЭМ и технологии


    В веб-разработке финальный продукт состоит из разных технологий (например, HTML, CSS, JavaScript). Основной принцип БЭМ-методологии — использовать единые термины и подходы к реализации во всех применяемых технологиях.

    JavaScript

    Чтобы работать в БЭМ-терминах и писать декларативно JavaScript, который можно разделять по уровням переопределения, нам понадобился собственный фреймворк — i-bem.

    БЭМ-дерево

    Типичная веб-разработка сводилась к тому, что мы писали HTML, затем нарезали его на шаблоны. При изменении дизайна приходилось менять HTML и шаблоны вручную.
    Чтобы избавиться от ручной работы, мы добавили новый уровень абстракции — БЭМ-дерево, которое позволяет работать со структурой веб-страницы в терминах блоков, элементов и модификаторов. БЭМ-дерево — это абстракция над DOM-деревом.

    БЭМ-дерево описывает все БЭМ-сущности, которые используются на странице, их состояния, порядок, вложенность. Оно может быть выражено любым форматом, который поддерживает древовидную структуру, например, XML или JSON.

    Пример

    Рассмотрим пример DOM-дерева:

    <header class="header">
        <img class="logo">
        <form class="search-form">
            <input type="input">
            <button type="button"></button>
        </form>
        <div class="lang-switcher"></div>
    </header>
    


    Ему соответствует такое БЭМ-дерево:

    header
        logo
        search-form
            input
            button
        lang-switcher
    


    Его можно сравнить с шаблонизатором Jade, но отличие в том, что мы пишем не HTML, а используем абстракции.

    Это же БЭМ-дерево будет иметь следующий вид в форматах XML и BEMJSON:

    XML

    <block:header>
        <block:logo/>
        <block:search-form>
            <block:input/>
            <block:button/>
        </block:search-form>
        <block:lang-switcher/>
    </block:header>
    


    BEMJSON — JavaScript-формат, который позволяет работать в БЭМ-терминах. BEMJSON позволяет абстрагироваться от HTML-разметки и описывать страницу в терминах блоков, элементов и модификаторов.

    {
        block: 'header',
        content : [
            { block : 'logo' },
            {
                block : 'search-form',
                content : [
                    { block : 'input' },
                    { block : 'button' }
                ]
            },
            { block : 'lang-switcher' }
        ]
    }
    


    Мы описываем страницу, которую хотим получить в браузере в виде БЭМ-дерева и не пишем HTML руками: шаблонизатор BEMHTML обрабатывает BEMJSON и генерируют HTML.


    БЭМ и инструменты


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

    Собирать все файлы вручную неудобно, мы начинаем автоматизировать большинство повторяющихся процессов. Появляются bem-tools — набор инструментов для работы с файлами по БЭМ-методологии. Позже на смену bem-tools пришел ENB.

    Чтобы иметь возможность собрать разрозненные файлы, ничего не знающие друг о друге, используется технология DEPS, которая указывает зависимости одного блока от другого или от набора блоков.

    Инструменты БЭМ направлены на то, чтоб разработчик писал код так, как ему удобно, а оптимизацией и подключением в проект только нужных файлов в правильном порядке занимались роботы.

    БЭМ и библиотеки


    Многие БЭМ-библиотеки можно найти в open source. Базовыми являются:

    • bem-core — базовая библиотека блоков, которая содержит JavaScript-фреймворк i-bem и 20 блоков-хелперов для разработки по БЭМ-методологии.
    • bem-components — универсальная библиотека готовых визуальных компонентов (блоков). Содержит контролы форм и другие базовые компоненты для построения интерфейсов.


    Библиотеку bem-components можно подключать по аналогии с Bootstrap: добавить предварительно собранные файлы библиотеки и вставить их в HTML страницы с помощью элементов link и script.

    <link rel="stylesheet" href="https://yastatic.net/bem-components/latest/desktop/bem-components.css">
    <script src="https://yastatic.net/bem-components/latest/desktop/bem-components.js+bemhtml.js"></script>
    


    Такой способ поставки называется Dist и включает предсобранный CSS- и JavaScript-код и шаблоны. С ним вам не потребуется инструменты для сборки или шаблонизаторы — блоки заранее собраны и работают.

    О том, как подключать файлы с CDN или локально, использовать bower или самостоятельно собрать файлы библиотеки из исходников, читайте в описании библиотеки.

    Заготовка проекта


    Быстро начать разработку БЭМ-проекта можно с помощью project-stub — проекта с заранее предустановленными технологиями и инструментами. Начинать знакомство с ним стоит с помощью быстрого старта по БЭМ.

    Расширенный пример использования project-stub описан в документе Создаем свой проект на БЭМ.

    И в заключение


    БЭМ-методология — это набор правил и рекомендаций по организации работы над проектом.

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

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

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

    Яндекс

    473,00

    Как мы делаем Яндекс

    Поделиться публикацией
    Комментарии 100
      +10
      Как верстали 10 лет назад


      Пример
      #foot div div div div...


      Слишком утрировать не надо. «Так верстали только мудаки», разве что.
        +5
        Конечно, не 10, а лет 15 лет назад, но похоже мудаком я был еще тем :)
          +11
          #foot div div div div {}
          


          Так повёрстывают и сейчас.
          –29
          За идею реализацию БЭМ двойка с минусом. Жирная.
            +6
            Концепции очень разумные. Сам долго плевался от синтаксиса и этих двойных подчеркиваний и всего такого, но в итоге сдался, потому что это чертовски удобно, вариантов используемого синтаксиса не так уж много (не любитель camelCase в CSS, поэтому остановился на BEM с синтаксисом Гарри Робертса, по примеру Гугла и Salesforce), а преимущества на дистанции — очень солидные.

            Все равно многие вещи остаются не очень очевидными, конечно, это не решает всех проблем именования в CSS, со временем все равно накапливается технический долг в проектах по части CSS и часто присутствуют проблемы интеграции с готовыми решениями/фреймворками вроде TWBS, Foundation, Semantic, итд, но, думаю, всему свое время. Может и BEM предложит что-то еще.
              –31
              Есть еще разумнее. Ставьте еще минусы.
                +5
                Пишите ещё неконструктивные комментарии.
                  –26
                  Лучше буду писать деструктивные. Потому, что сама конструкция, заложенная в БЭМ недеструктивна. Так, что почем купил, за то и продаю.Хотя я БЭМ не покупал :) Хочу еще минусов. Сыпьте.
                    +3
                    Комментарии типа «вам тут всем требуется толерантное отношение, а я стою весь в белом, красивый, д'Артанян» сильно раздражают. Минусы точно не за иное мнение, а за то, что вам в жизни не повезло.

                    Не согласен — обоснуй. А если есть просто желание взписнуть безадресный и бессмысленный поток эмоций во вселенную, то чему вы удивляетесь? Я бы и сам влепил минусок-другой.
                      –6
                      Цитирую самого себя.«Конструкция, заложенная в БЭМ недеструктивна» — это основная мысль. Если вы её не уловили, то я в этом невиновен. Кто сказал, что я удивляюсь? Влепите «минусок-другой» — я же сказал — хочу! У нас, что не делай всё Друпал получается. Я не знаю в чем не повезло. Я совсем «не красивый и не стою, а сижу». Я высказался относительно БЭМ. Не нравится. Ничем не могу помочь. Точнее могу, но за деньги. И не вам, а горе-архитекторам БЭМ
                        +3
                        Уважаемый. «Конструкция, заложенная в БЭМ недеструктивна» — так может писать только тот, кто обладает общепринятым авторитетом. Скажем, я поверю на слово многому из того что скажет [вставьте сюда *уважаемого* вами человека]. Человек из ниоткуда, да ещё и с минусовой кармой изъявлять истины, конечно, может. Но это выглядит И смешно И глупо, простите.

                        Что бы человека кто-то слушал надо либо заслужить авторитет заранее, либо чётко обосновывать свои слова. Вот я могу написать: «вавилон это не город». Будете спорить или примете на веру?

                        Ещё раз. Летящие Вам минусы никакого отношения к БЭМ вообще не имеют.
                          –3
                          Я не зарабатываю авторитет. Я просто смотрю на то, что изображено или написано и комментирую. Вполне возможно есть сторонники такого подхода. Но я не из их числа. Я не изъявляю истины. Я выражаю своё отношение к БЭМ. На текущий момент оно строго отрицательно. И всё.
                            +1
                            Хабр — это такое место, где комментарии должны обладать ценностью. Комментарии, не соответствующие этому критерию, атакуются иммунной системой. Неаргументированное мнение никому не известного человека ценностью не обладает.
                            • НЛО прилетело и опубликовало эту надпись здесь
                                –3
                                Спасибо, но что-то мне говорит, что бэмовцы уже «не переобуются». Клинический случай. Думаю для этого сообщества моё компетентное мнение не нужно. У меня другая компания.
                                  0
                                  Компетентность в вопросе — это когда человек может убедительно аргументировать свое мнение. А вы для высказывания «За идею реализацию БЭМ двойка с минусом. Жирная.» — никаких аргументов не привели.
                                    0
                                    Мне понравилась вот эта ссылка http://maximilyahov.ru/blog/all/tri-zakona-kritiki/ я думаю, это помогло бы убрать недопонимание между вами и минусующими. Точнее минусов бы не было, зато была бы интересная беседа, от которой выиграли бы все.
                              +8
                              У горе-архитекторов БЭМ есть вакансии в Мск и Симферополе. Будем рады обсудить потенциальную помощь. Деньги есть ;)
                              +1
                              Очевидно единственный, но серьезный недостаток БЭМ, это то, что он убивают саму идею каскадности превращая css в ss.
                              Причем БЭМ не исправляет недостатки реализации каскадности изначально заложенные в css, а именно пытается устранить ее влияние полностью.
                              Не согласны?
                                0
                                Не согласен. Есть модификаторы, которе допускают использование каскадов.
                                  0
                                  Ну возможно я перегибаю палку, когда пишу «полностью» и правильно бы было написать «почти полностью», но в целом же я прав? Вот смотрите — есть у меня страничка для мальчиков где все элементы управления, кнопочки и т.п. синенькие, а есть для девочек где они розовенькие.
                                  Переношу я блок с кнопкой на страницу для девочек и получаю… синенькую кнопочку. С чего бы это? А мне надо поменять модификатор.
                                  Ну вы поняли.
                                  Смысл в том что я теряю целостность стиля и вместо того чтобы работать со страницей работаю с кучей маленьких страниц.
                                  Хуже только атомарная верстка с этой точки зрения.

                                  (*не имею ничего против БЭМ — система вполне имеет право на жизнь, но не стоит говорить что она лечит web — нет, только прячет некоторые симптомы тяжело больного)
                                0
                                Именно.
                                Вот только это не недостаток, а особенность. Каскадность в больших проектах приносит больше проблем, чем пользы.
                                Реально она нужна только для написания стилей к плохой чужой вёрстке, например — морд на чужие сайты.

                                >Переношу я блок с кнопкой на страницу для девочек и получаю… синенькую кнопочку. С чего бы это? А мне надо поменять модификатор.

                                А почему у вас в этом случае модификатор висит на кнопочке, а не на body?
                                  0
                                  Думаю, что не единственный. Отказ от каскадности это одно из следствий еще более серьезной проблемы — сопровождаемость верстки в HTML. Если смотреть на сапровождаемость верстки через HTML, CSS со своим разнообразием всегда будет проблемой для БЭМ.
                                    +2
                                    Ещё стоит помнить, что термин «каскадный» из названия технологии, это не про составные селекторы «div .class», а про каскадное применение правил из разных деклараций. БЭМ эту идею не убивает, а использует на полную катушку. Использования селекторов по БЭМ неймингу, позволяет избегать неоправданного повышения спецефичности селектора, при сохранении изолированности. Таким образом, достигается более предсказуемое применение стилей.
                                      +2
                                      авторитетные ссылки по теме:
                                      * каскад www.w3.org/TR/2009/CR-CSS2-20090908/cascade.html#cascade
                                      * специфичность developer.mozilla.org/ru/docs/Web/CSS/Specificity
                            +5
                            С завидной регулярностью Я публикует заметки в духе «Как уверовать в БЭМ». Никто не покупает или в чем причина?
                              +2
                              Видимо, трудно конкурировать с традиционными конфессиями.
                                +5
                                Да ладно, БЭМ однозначно взлетел, причем не только в России, но и в мире — а это редко кому удается.
                                  +3
                                  Распространённее технология → больше знающих её людей → меньше времени на обучение новых сотрудников.
                                    0
                                    Покупают. Material Design Lite например
                                    0
                                    По-моему, где-то уже спрашивал про это, но внятного ответа не получил:

                                    БЭМ — это только про фронтенд, или есть методики/примеры, как по БЭМу организовать взаимодействие с бэкендом, используя разные серверные технологии? Например, можно ли как-то энкапсулировать логику, соответствующую [сложным] блокам, в серверном коде, ajax API и т.п.?
                                    0
                                    Видел интересный кейс применения БЭМ. Все было красиво сверстано, блоки в папочках, судя по всему какие-то тулы для БЭМа использовались и т.д. Вот передали нам штук 50 так сверстанных макетов, выглядит все красиво, но при попытки собрать их в SPA начался ад и содомия, все начало расползаться ломаться и взрываться. Видимо формального раскладывания CSS по папочкам — не достаточно для создания качественной верстки.
                                      +2
                                      Все правильно — разложив все по папочкам это еще не значит что все не взорвется. Особенно если руки из одного места
                                      +1
                                      Не пойму — в интернете мало инфы на эту тему?
                                      Смысл каждый раз расписывать значение каждой буквы, что такое Б, что такое Э, что такое М?!
                                      Кому нужно, и считает это клёвым — уже юзает, либо просто в курсе этого, кому не нужно — обходит стороной.

                                      Вопрос — чего вы это всем навязываете постоянными постами?
                                        +4
                                        Нуждо запретить пропаганду БЭМ, ввести штраф за публичную демонстрацию БЭМ, etc.
                                          –3
                                          Нужно в W3C создать отдел чистки интернета от БЭМ и выжигать все напалмом.
                                          –1
                                          Так ведь в первом же абзаце ответ написан ;)
                                          Постоянно спрашивают — вот и пишем.
                                            +1
                                            На Тостере тоже постоянно спрашивают — какой язык программирования изучать =)) Так что, то что спрашивают — ни о чем не говорит.
                                          –7
                                          Siron, опять тебя понесло. Резонерство это не твоё. Равнодушнее ко всему относись. А то минусиков мне навтыкал. Чего-то имунная система хабра молчит…
                                          tadatuta, спасибо за предложение. Я высказывал свои соображения г. Билецкому. Он ничего не ответил «неизвестному» мне. Видимо будет на своей волне, до тех пор пока не смоет другой.
                                          deniskreshikhin порадовало, что Вы понимаете разницу между зависимостями (dependency) и сцепленностями (cohesion). Это действительно очень важно понимать.
                                          Я подумаю над тем почему фраза «Конструкция, заложенная в БЭМ недеструктивна»" не обладает ценностью. На мой взгляд в ней вся суть БЭМ. Так как моя карма сильно ушла в минус возможно буду радовать вас каментами не чаще 1 раза в час. Соряйте!
                                            +4
                                            Держите нас в курсе.
                                            +1
                                            Вот есть у меня такой код:

                                            <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, какой-то.

                                              +3
                                              <div class="date-form">
                                                  <div class="date-form__item date-form__item_type_day">
                                                      <label class="date-form__label">Day</label>
                                                      <input class="date-form__input" type="text" name="day"/>
                                                  </div>
                                                  <div class="date-form__item date-form__item_type_month">
                                                      <label class="date-form__label">Month</label>
                                                      <input class="date-form__input" type="text" name="month"/>
                                                  </div>
                                                  <div class="date-form__item date-form__item_type_year">
                                                      <label class="date-form__label">Year</label>
                                                      <input class="date-form__input" type="text" name="year"/>
                                                  </div>
                                              </div>
                                              
                                                0
                                                БЭМ-методология не рекомендует создавать элементы элементов, так как такая схема block__elem1__elem2 не дает свободно изменять внутреннюю структуру блока. Подробный ответ с примерами есть в FAQ на bem.info.
                                                  +1
                                                  Предложенная banzalik разметка в BEMJSON:

                                                  {
                                                    "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
                                                  0
                                                  Если интересно посмотреть на БЭМ + Sailsjs (как Rails только на javascript), у меня есть
                                                    0
                                                    Почему бы просто не использовать CSSModules?
                                                      +1
                                                      CSSModules про скоупинг в CSS, а БЭМ — про компонентный подход. Как Web Components, но от практикующих разработчиков.

                                                      CSSModules можно использовать вместе с БЭМ, другое дело, что «классический» БЭМ тоже более-менее решает задачу со скоупингом :)
                                                        –5
                                                        Куда же без scope в наше то время. Только зачем от id гордо отказываться было? Не вполне ясно…
                                                          +1
                                                          id обязан быть уникальным, и отсюда вытекают два неприятных свойства:
                                                          1) это очень трудно гарантировать
                                                          2) если использовать id для идентификации, то на странице может быть только один инстанс такого типа — а это может «выстреливать» в самые неожиданные моменты, когда вдруг понадобится второй

                                                          class же во всём может заменить id и при этом не обладает такими недостатками

                                                          раньше (лет 10 назад) у id было преимущество про скорость (браузеры не сильно оптимизировали DOM-дерево и не строили никаких кешей по class), но со временем эта разница существенно сгладилась
                                                            –2
                                                            Приятно, что хоть какой профи понял реплику. Возражение следующее: вы заведомо отказываетесь от неименованных объектов. Такой отказ играет против пластичности БЭМ. Ну конечно это ваше право:)
                                                              +1
                                                              От именованных объектов никто не отказывается. Просто для них не пишется специфических стилей.
                                                              А в JS — по прежнему работаем со всеми способами идентификации объекта.
                                                                –1
                                                                Внимательнее прочитайте — я написал от «неименованных» :)). Проще говоря:[{},{}]
                                                                  0
                                                                  Тогда я не понял, что Вы называете неименованными объектами, и как предлагаете писать стили для них.
                                                                    –1
                                                                    Я рассуждаю в терминах объектов. Нода — эта именованный объект. Изнутри ноды мы не можем достучаться до её имени поэтому в ноде правильно иметь две части: параметры ноды (имя, и расширенные параметры id, parent и т.д. — типа конструктора в классе) и её контент. Если этого нет то, как вы с этим работаете? :).
                                                                      0
                                                                      «Изнутри» — это откуда? Приведите пример кода, в котором требуется достучаться до ноды изнутри.
                                                                        0
                                                                        С чего это нода именованный объект? Нода — элемент коллекции, иерархии и т. п., из которых её можно выбрать по разным признакам (селекторам). Имя — необязательный, а иногда и невозможный (текстовая нода, например) атрибут ноды, лишь один из признаков ноды, по которой её можно выбрать из множества остальных нод.

                                                                        Или вы под нодой имеете в виду только ноду типа HTMLElement, а под её именем — имя этого элемента?
                                                                          0
                                                                          Значение текстовой ноды не может быть массивом или объектом. Посему текстовая нода не может содержать объект или массив. Если бы я рассуждал в терминах массивов я бы сказал, что нода это — именованный массив. Но где тогда хранить ссылку на родителя? А вот контент ноды да может быть и тем и тем и тем.
                                                                  +2
                                                                  честно говоря я почитал ваш подтред с Zenitchik, но не смог понять, что Вы называете неименованными объектами и связано ли это с id

                                                                  случайно речь не про
                                                                  <div class="my-block" data-bem='{ "my-block" : {} }'>...
                                                                  пустой объект в атрибуте data-bem?
                                                          –5
                                                          чем оно отличается от того же smacss.com?

                                                          почему стоит использовать БУЭМ?

                                                          Был же OOCSS и др до БЭМ, вы по сути ничего не придумали, а просто другой нейминг сделали.
                                                            +3
                                                            БЭМ — это не только про CSS. В чем отличие БЭМ от OOCSS, AMCSS, SMACSS, SUITCSS можно почитать на нашем сайте.

                                                              –5
                                                              точно БЭМ это еще никчемная js библиотека, набором совершенно идиотских утилит и сборщика
                                                              –4
                                                              Надо же доить акционеров яндекса. Для этого и придумываются «новые методологии» и «псевдотехнологии».
                                                                –5
                                                                да не, надо судиться с гуглом по поводу их собственного андройда и указывать гуглу как им распоряжаться своим продуктом. Еще надо ломать кинопоиск, запуская его на убогом БЭМ и пытаться сказать, что БЭМ это новый крутой подход в разработке, а по сути ничего в нем и нет нового
                                                                  0
                                                                  Не надо критиковать js и тем более nodejs. Они тут не причём. Как кстати и Гугл. Гугл идет своим путем и правильно идёт! Переводчик Яндекса мне нравится больше. Но и в нем встречаются ошибки. В больших компаниях много разных трендов и команд под общим Яндекс лейблом и главное бюджетом. Какие-то надо поддерживать, а какие разгонять. Это проблема не только яндекса, но и других гигантов индустрии.
                                                                    –1
                                                                    что? где ты увидил критику js и nodejs? этот комментарий о чем вообще?
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                +1
                                                                С переходом на BEM и отказ от каскадов привел к тому, что в какой-то момент reset.css стал самой медленной частью CSS файла. Более того одно из требований к блоку — самодостаточность и reset.css не вписывался в концепцию.
                                                                Последний раз, когда я интересовался вопросом — самой медленной частью CSS бал браузерный CSS, который подключается автоматически к любой странице самим браузером.
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0
                                                                    БЭМ не предполагает никаких супер-блоков, блоки можно без ограничейний вкладывать друг в друга.
                                                                    Про обертки есть пост на форуме на bem.info: https://ru.bem.info/forum/656/
                                                                      +1
                                                                      Это просто блок-раскладка c именем 'b-layout'. Как grid в Bootstrap.
                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                            +1
                                                                            Все, что повторяется больше одного раза (или может повториться больше одного раза) — надо делать блоком.
                                                                            В вашем случаи абстрактный код может выглядеть так.

                                                                            <form class="form">
                                                                                <input class="input form__input">
                                                                                <input type="submit" class="button form__submit">
                                                                            <form>
                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                +1
                                                                                Да: https://ru.bem.info/method/key-concepts/#Микс

                                                                                И в FAQ поиск по «микс»: https://ru.bem.info/faq/
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                      +1
                                                                      Блок — независимый компонент. На него не должны влиять CSS-правила, созданные для всей страницы. Это нарушает независимость блоков и затрудняет их повторное использование.
                                                                      Подробнее и с примером можно почитать тут.
                                                                        +1
                                                                        Банально из-за экономии ресурсов. По методологии блок определяет сам всё для себя, в том числе и те стили, которые сброшены (вернее определены) глобально. А если всё определяется блоком, то зачем глобальный сброс?
                                                                          0
                                                                          Подскажите, где можно почитать про то, как переопределить все правила, ничего не забыв? Наверняка же кто-то уже перечислил весь список правил, которые могут быть унаследованы сверху.
                                                                            +1
                                                                              0
                                                                              Спасибо! Список исчерпывающий?
                                                                              +1
                                                                              Есть наследование свойств, а есть каскад правил. Со свойствами как раз проблем обычно нет — открываешь описание элемента и переопределяешь все свойства, помеченные как наследуемые от родительского (общего списка нет формально, есть разной степени актуальности и полноты агрегаты). Проблемы обычно с правилами по умолчанию в браузерах, как минимум с теми, для которых в спецификации явно указано, что определяются разработчиком клиента, а не имеют стандартное значение.

                                                                              Варианты решения:

                                                                              1. определять явно все свойства, которые есть у элемента, как собственные, так и наследуемые, по спецификации, не забыв про вендорские

                                                                              2. проводить анализ значений свойств по умолчанию по спецификации и задавать те, которые отданы на откуп вендорам

                                                                              3. проводить анализ значений свойств по умолчанию в целевых агентах и задавать те, которые де-факто отличаются

                                                                              4. совмещать 2 и 3

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

                                                                              В общем случае, стремление «ничего не забыть» похвально, но недостижимо, поскольку новые свойства и их реализации в агентах появляются постоянно, поэтому разумно использовать переопределение только очевидных свойств, либо не имеющих стандартного значения по умолчанию, либо широко известных как имеющих разные реализации, не смотря на спецификацию, а дальше решать проблемы по мере поступления.
                                                                          0
                                                                          Просто оставлю это тут…
                                                                            +1
                                                                            Мы долго экспериментировали с префиксами в именах, но в итоге отказались от них.

                                                                            Насчет префиксов — они необходимы. Бывает так, что блоки (повторно используемые компоненты) требуется встроить в другие приложения и экосистемы. Причем заранее, только начиная разработку и выбирая методологию, вы не можете быть уверены в том, что компоненты не понадобятся в еще одном приложении, которое появится через пару лет. А еще если это приложение само использовало методологию БЭМ, и там также есть «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-», но данный префикс слишком абстрактный. Как будто больше пользовательские интерфейсы никто не разрабатывает.
                                                                              +2
                                                                              Говоря о популярности БЭМ, и что сам ГУГЛ его использует в mdl,
                                                                              надо всё-таки по-честному разделять подход к наименованию классов, который и правда хорош и распространен (с небольшими изменениями у того же Гугл), и инструменты типа bem-tools, которые мягко говоря медленные ) и никакой ГУГЛ их использовать никогда не будет.

                                                                              Да, есть enb, но не странно ли, что один разработчик в свободное от работы время, «на коленке» написал сборщик,
                                                                              работающий в разы быстрее bem-tools, непонятно, чем же тогда занималась вся команда БЭМ? Наверное писала статьи на хабр… )

                                                                              Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
                                                                              И это совсем не обнадеживает.

                                                                              Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-ситаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller

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

                                                                              PS:
                                                                              В части «с чего всё начиналось» можно было рассказать и о «y5.js» который был до лего-бэма
                                                                              и был благополучно похоронен на основании тех же доводов о «пороге вхождения»
                                                                                +1
                                                                                кроме того, про что написал tadatuta habrahabr.ru/company/yandex/blog/276035/#comment_8767005 (жаль у меня нет кармы ставить плюсики каментам), не могу молчать про похороны y5, т.к. «из первых рук» знаю про ситуацию — основная причина была в закрытости кода и невозможности подключить к сообществу внешних людей
                                                                                  0
                                                                                  Сережа, где же твоя карма? ) Я присутствовал на разговоре Бобука, кажется с Надей (уже не помню точно) Речь шла о том, что найти разработчиков со знанием jQuery сильно легче чем со знанием y5. Ну и сам помнишь, после ухода Андрея ее банально некому было развивать
                                                                                    +1
                                                                                    настоящая карма всегда со мной ;-) а вот почему нельзя оценивать комментарии не написав ни одного поста, это пусть останется на карме разработчиков хабра

                                                                                    то что ты говоришь, это уже следствие — после ухода Андрея мы его вполне развивали аналогичными темпами с Лёшей и Лёней, вот только нужно было экспоненциально растить темпы (без опенсорса это практически не реально)
                                                                                +2
                                                                                Несколько поинтов:

                                                                                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.
                                                                                  +2
                                                                                  Хорошая презентация: ihorzenich.github.io/talks/2015/frontendweekend-bem

                                                                                  С нее хорошо втягиваться в БЭМ, там только суть без фулстека, подходит тем, кто вообще не шарит.
                                                                                    –4
                                                                                    В БЭМ лучше не втягиваться. Как система спроектирована, так она и ездит. Спроектированна она плохо. Кстати, не только она. Это в утешение. Вопрос почему кто-то «это» продвигает и популяризирует имеет легкий и честный ответ. Хочется славы и то, что ей сопутствует. Много и быстро. Всё было бы замечательно, если бы было замечательно всё остальное…
                                                                                      +1
                                                                                      А что по-вашему летит? Желательно, что бы оно уверенно летело уже лет так 5.
                                                                                        –2
                                                                                        Топик надо было бы назвать БЭМ-методология: и кому эта м… я нужна?
                                                                                        Ангуляр и БЭМ в том виде, в котором они есть надо отправить туда куда им и место — в топку. Нет не 5. Спросите лучше г. Белицкого. Я ему подробно всё пожелал.
                                                                                          +2
                                                                                          Хорошо, БЭМ и Ангуляр не летят. Что летит то?
                                                                                            0
                                                                                            Пока ничего! Я знаю, что есть лисп реализации, портированные на ассемблер! Но они недоступны широкому кругу людей и даже неширокому тоже (((. В общем виде допустим, есть запрос, есть что-то похоже на JSONNET, исполняемый на сервере. Вы преобразуете url в json запрос (типа JSONPath) к исполняемому json и возвращаете тот рендер странички, который вам нужен. Так как jsonnet это данные с ними можно проделывать всё то, что можно с ними проделывать.
                                                                                    0
                                                                                    Ириша вам дали задание минусовать каждый мой пост? Ну хоть какое то применение нашли вашим способностям. Это не может не радовать.
                                                                                      +3
                                                                                      Не знаю, кто такая Ириша, но глядя на те 56 комментов, которые вы оставили на Хабре, становится очевидно, что дело не в ней ;)
                                                                                      0
                                                                                      На эту тему еще есть вебинар «Основы БЭМ-методология: необходимость появления, история и основные понятия», если кому-то интересно покопаться в истории.

                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                      Самое читаемое