В начале года я собрал статью о BEM и SMACSS, которая была посвящена путанице при выборе методологии CSS. Я связался с разными разработчиками и получил их советы, истории успеха и ужасы в надежде, что другие смогут извлечь уроки из их опыта использования этих популярных методологий CSS.
Статья была воспринята довольно хорошо, но я постоянно повторял вопрос о БЭМ, который я неоднократно встречал в статье: как вы справляетесь с БЭМ в масштабе?
Было хорошо и приятно сказать, что БЭМ полезен (это так!), Но часто в Интернете руководства по БЭМ придерживаются основ. Они говорят вам, чтобы все было упорядочено в block__element--modifier но не так много указаний о том, что делать, когда что-то запуталось. block__element__subelement--modifier порядке? Есть ли лучшая практика для размещения ваших файлов CSS? Следует ли использовать @extend для наследования значений родительского класса или перечислять их в своем HTML?
В этой статье я хотел узнать мысли разработчиков, которые уже имели опыт работы с BEM в масштабе — что они делают? Какие уроки они извлекли в процессе, которые нам было бы полезно знать заранее?
Одна вещь, которую вы найдете, это то, что есть разные мнения — но это нормально. Я попытался включить как можно больше ответов, даже если они содержат противоречивые мнения, чтобы читатели могли составить собственное мнение.
Некоторый Фон
БЭМ возникла в Yandex , российской поисковой системе. С тех пор он превратился в два различных потока использования — это может быть либо весь BEM-стек, созданный Яндексом (CSS, JS, HTML-шаблоны и инструменты разработки), либо это может быть только методология CSS, стоящая за ним.
Последний подход развился от концепции Яндекса через идеи Николаса Галлахера , Гарри Робертса и многих других. Команда CSS-Tricks недавно также отлично написала методологию CSS BEM — ее стоит проверить!
Эта статья будет охватывать немного обоих миров, так как я думал, что было бы лучше включить обе точки зрения. Тем не менее, довольно большая часть респондентов фокусируется исключительно на методологии CSS, а не на стоке Яндекс БЭМ.
Талантливые разработчики, которые впускают меня в свои умы
Я начну с того, что представлю разработчиков, которые были настолько любезны, что позволили мне вспомнить некоторые советы и рекомендации по использованию БЭМ в масштабе. Мне посчастливилось найти энтузиастов БЭМ со всего мира — я получил ответы из Нидерландов, Швеции, Великобритании, Крыма и Эстонии! Большое спасибо всем им, что нашли время ответить на мои вопросы.
- Боб Дондервинкель , разработчик внешнего интерфейса из Роттердама — сайт , Twitter
- Хэмиш Таплин , фронтенд-разработчик, работающий на Bluegg in Cardiff — Website , Twitter
- Гарри Робертс , консультант Front-end Architect, дизайнер, разработчик и абсолютный гуру BEM из Великобритании — веб-сайт , Twitter
- Серж Херкюль , разработчик Teamweek — веб-сайт , Twitter
- Владимир Гриненко , руководитель группы разработчиков БЭМ в Яндексе — Сайт , Twitter
- Владимир Старков , фронтенд -разработчик из Швеции, который является одним из основателей getbem.com и ранее также работал в Яндексе — Сайт , Twitter
Давайте начнем смотреть на советы от этих разработчиков!
Будьте осторожны с вложенностью
Вложение — одна из самых больших опасностей, которые я видел с командами разработчиков, использующими БЭМ. Это очень легко пойти за борт и сделать вещи намного сложнее, чем необходимо. Я хотел знать, называет ли класс .block__element__subelement--modifier порядке? Или вы должны придерживаться не более двух уровней parent и child в .block__element--modifier ? Разные разработчики имеют разные уровни вложенности, с которыми они в порядке, поэтому я рассмотрю обе точки зрения.
Нет вложенности за два уровня
Это было моим личным предпочтением, и разработчики, с которыми я беседовал, чаще всего следуют практике.
Владимир Старков отметил, что его беспокоит block__element__subelement--modifier вложенные классы block__element__subelement--modifier , заявив, что «это неправильный путь, вы всегда должны иметь возможность использовать один элемент без другого».
Боб Дондервинкель также постепенно перешел к такому подходу:
« block__element__subelement—modifier я использовал block__element__subelement—modifier , но это не оптимально и немного излишне. Поэтому я стараюсь придерживаться block__element—modifier сейчас, и это также проще для глаз;) »
«Это на самом деле не служит цели и усложняет ваш CSS. А также, возможно, дополнительный размер файла, который могут создавать некоторые стили вложенности Sass / LESS. Получающийся CSS может стать довольно обширным ».
Владимир Гриненко из Яндекса также соглашается избегать вложения, предлагая увеличить имя элемента при необходимости, а не добавлять больше уровней вложения:
«Нет необходимости напоминать вложение в именах сущностей. Для этого достаточно структуры DOM. Вложение может измениться в будущем, и лучший способ избежать переименования вещей при рефакторинге — это правильно назвать их с самого начала.
В случае, если вам действительно нужно напоминать вложенность в имени, подумайте над тем, чтобы сделать это только с более длинным именем элемента: block__element-subelement »
Гарри Робертс объяснил мне идею этого, пожалуй, лучшим образом, который я когда-либо видел, поэтому я включил его ниже, почти полностью неотредактированный:
«Одна важная вещь, которую нужно знать о BEM — и то, что, как я чувствую, вызывает проблемы у многих разработчиков, — это то, что вы не проходите через каждый уровень DOM. Чтобы использовать метафору, следующее неверно:
.person {} .person__head {} .person__head__face {} .person__head__face__eye {} .person__head__face__eye__pupil {}
«Это ужасно многословно и навязывает нам структуру DOM; это очень негибко. Вместо этого мы должны написать:
.person {} .person__head {} .person__face {} .person__eye {} .person__pupil {}
«Это гораздо более кратко; это не навязывает нам какую-либо структуру DOM, и мы можем визуально сделать отступы для набора правил, чтобы показать нам подразумеваемую структуру DOM.
«Если вам нужно вложить один блок в другой, просто используйте традиционное вложение. Чтобы продолжить нашу метафору:
.person { clothing: pyjamas; .outside & { clothing: covered; } }
«На этот раз мы хотим стилизовать Person, потому что он снаружи — нам не нужно вызывать или использовать что-либо BEMmy здесь. (Обратите внимание, что мы используем вложенность родительского селектора Sass для лучшей инкапсуляции здесь.) Однако, в качестве альтернативы, мы могли бы использовать что-то вроде этого:
.person { clothing: pyjamas; } .person--covered { clothing: covered; }
«Мы можем использовать БЭМ здесь, чтобы создать вариацию человека, которого можно охватить независимо от того, где он находится».
Хэмиш Таплин на самом деле не следует строгим правилам, но стремится сохранить элементы и субэлементы, где это возможно:
«Я стараюсь сделать вещи максимально простыми. У меня нет никаких реальных предпочтений, так как это происходит так редко, но я обычно нахожу, что достаточно просто разделить элемент / подэлемент на его собственный элемент. Примером этого может быть всякий раз, когда у вас есть несколько повторяющихся элементов внутри элемента, который имеет свои собственные компоненты (например, верхний / нижний колонтитулы). Например, вы можете сделать это:
.list__header .list__items .list__item .list__item__header .list__item__body .list__item .list__item__header .list__item__body .list__item .list__item__header .list__item__body .list__footer
«Однако я предпочитаю просто отделить эти элементы:
.list__header .list__items .list-item .list-item__header .list-item__body .list-item .list-item__header .list-item__body .list-item .list-item__header .list-item__body .list__footer
«Итак, теперь у нас есть элемент« список »и элемент« список-элемент », который не привязан к« списку ». На самом деле я не могу комментировать плюсы и минусы этого подхода, потому что я об этом не задумывался, но до сих пор он работал хорошо для меня! »
Однако не все согласны со строгим подходом
Серж Геркюль придерживался другого подхода к ограничениям вложенности, поэтому я должен упомянуть о других командах, которые делают то же самое. Его команда выходит за пределы двух уровней. Он сказал:
«Мы используем block__element__subelement--modifier когда это необходимо. Постарайтесь не быть слишком строгими с тем, как «оригинальный» БЭМ видит вещи и приспосабливает их к вашим собственным потребностям ».
Будьте осторожны с тем, где вы начинаете свою область блока
Распространенная ошибка Гарри Робертса состоит в том, что разработчики слишком рано запускают свои блоки. Он приводит следующий пример некорректного CSS:
.room {} .room__floor {} .room__desk {} .room__laptop {}
Гарри объясняет: «Здесь мы видим, что приглядываем ноутбук к столу в комнату. Проблема в том, что этот ноутбук может быть в моей сумке в багажнике машины; этот стол можно было перенести в коридор; ноутбук можно поставить прямо на пол комнаты ».
Вместо этого следует сосредоточиться на выделении элементов DOM, которые могут жить независимо друг от друга. Начните свой блок с «самого маленького, самого самостоятельного бита». В качестве примера Гарри предоставил следующее решение для некорректного CSS выше:
.room {} .room__floor {} .desk {} .laptop {}
Гарри отмечает: «Ноутбук теперь ни от чего не зависит, как и от стола. Так и должно быть ».
Разделяй свой CSS на простые для понимания файлы
Серж Херкюль сосредоточился на модульном хранении и в отдельных файлах, чтобы помочь в расширении БЭМ. Он сказал: «Весь наш SPA состоит из модулей. Грубо говоря, у нас есть файл SCSS для каждого модуля или группы модулей (если он сделан из более мелких модулей) ». Он рекомендует модульный подход для CSS и JS:« Попробуйте объединить ваши модули JS и CSS, чтобы они имели одно и то же имя ( profile_picture.js и profile_picture.scss ). »
Гарри Робертс говорит, что «каждый файл должен быть как можно меньше, но настолько большим, насколько это необходимо».
Владимир Старков разделил файлы по блокам, модификаторам и элементам, когда ранее работал в Яндексе, но обнаружил, что проще сосредоточиться на разделении по блокам:
«В Яндексе мы обычно разделяем стили на блок, его модификаторы, его элементы и их модификаторы. Но на самом деле очень трудно поддерживать все эти разделения. Вот почему в проектах для домашних животных я и бывшие яндексеры поддерживаем структуру «один файл на блок», которая является гибкой и достаточно хорошей для поддержки и поддержки. Лучший совет — извлечь блоки в разные файлы, по одному блоку на файл. Владимир ( @mistakster ) опубликовал блестящую статью на английском языке по адресу frontendbabel.info/articles/bem-with-css-preprocessors/, в которой объясняется, как поддерживать структуру вашего селектора в файлах блоков ».
Боб Дондервинкель рассматривает свой подход к каждому проекту в зависимости от сложности, но также адаптирует некоторые концепции SMACSS:
«Это зависит от проекта. Я начал с использования разных файлов для каждого блока, а затем, возможно, файлов для каждого элемента и модификатора, если они стали обширными. Но в настоящее время я также часто использую базовые показатели SMACSS для файлов и заполняю их с помощью BEM CSS ».
Владимир Гриненко говорит, что в центре внимания Яндекса — разделение на блоки, элементы и модификаторы разделяются при необходимости:
«Мы храним каждый блок в отдельной папке. Для элементов и модификаторов дополнительные папки являются необязательными (наличие их в разных файлах дает нам возможность построить проект только с необходимыми частями). например
blocks/ button/ button.css header/ __logo/ header__logo.css header.css footer/ footer.css
«Затем инструменты сборки смотрят, какие сущности БЭМ (блоки, элементы и модификаторы) существуют, и объединяют необходимые файлы в правильном порядке».
Хэмиш Тэплин обнаружил, что его стиль структурирования CSS-файлов со временем изменился и дал представление о том, куда он движется и почему:
«Ранее я создавал свой Sass в структуре, вдохновленной SMACSS:
- основа (базовый стиль для типографики, форм, таблиц, сетки и т. д.)
- помощники (функции Sass и миксины)
- модули (Мои модули БЭМ)
- продавец (сторонний материал)
«Содержимое всего, кроме« модулей », останется практически неизменным от проекта к проекту, при этом для каждого проекта будет выполняться только некоторая« базовая »стилизация. Это будет включать в себя базовый типографский стиль (заголовки, основной текст и т. Д.) Для этого проекта, а стили, такие как таблицы и формы, будут стилизованы.
«Все остальное входит в« модули »с одним файлом на модуль. Это может выглядеть примерно так:
- modules -- article -- avatar -- dropdown -- feature -- list -- media -- nav -- panel -- section
«Однако выгрузка всего в« модуле »на самом деле не работала для меня, так как не каждый бит стиля можно абстрагировать в повторно используемый модуль. Очевидно, что написание кода многократного использования должно быть сделано как можно больше, но реалии сроков и бюджетов диктуют, что иногда вам просто нужно что-то придумать и двигаться дальше. Я задумался о поиске лучшего пути и экспериментировал с удалением синтаксиса BEM для стилей, который не предназначен для повторного использования. Я опробовал это на нескольких проектах и не очень-то доволен этим ».
Затем на Хэмиша повлияла статья Гарри Робертса о пространстве имен, которую сам Гарри на самом деле объясняет чуть ниже в этой статье (это замечательно, когда ответы так здорово соединяются!):
«Несколько недель назад Гарри Робертс опубликовал статью об использовании пространства имен для лучшего контроля над крупномасштабными кодовыми базами. Хотя я не полностью принял его подход, он делает некоторые действительно хорошие замечания о типах абстракций, которые он использует. Это сделало несколько вещей «щелчком» для меня, и я предложил новый подход к структурированию моего Sass, который я недавно пробовал:
- база
- компоненты
- помощники
- объекты
- продавец
«Единственное реальное отличие до сих пор состоит в том, что я разделил то, что я ранее называл« модулями », на две папки, которые назывались« объекты »и« компоненты ». По сути, «объекты» — это чистые абстракции, такие как объект «медиа» и моя собственная сеточная система, тогда как «компоненты» — это отдельные реализации стилей, такие как «выпадающий список» или «форма регистрации». Эти компоненты могут даже основываться на «объекте», но, скорее всего, будут зависеть от проекта, в то время как «объекты» гораздо более пригодны для повторного использования между проектами ».
ITCSS и заказ источника
У Гарри Робертса есть своя собственная методология структурирования BEM CSS, называемая ITCSS, которая упрощает управление и масштабирование. Гарри объясняет это как методологию, которая позволяет «разбивать свои проекты на основе специфики, явности и охвата». Он фокусируется на определенном порядке исходного кода CSS, разбивая стили на слои разного уровня специфичности. Более специфические стили имеют слои, расположенные ближе к концу вашего CSS, а глобальные переменные, миксины и стили находятся в слоях в начале.
Если вам нужна дополнительная информация о платформе ITCSS, презентация Гарри «Управление проектами CSS с помощью ITCSS» является отличным ресурсом (если вы предпочитаете просто слайды, а не ссылку на YouTube, их можно найти здесь ). ITCSS — это действительно хорошо продуманная структура для поддержания CSS управляемой в масштабе, и на нее определенно стоит обратить внимание.
Пространства имен
Гарри Робертс рекомендует дополнить БЭМ пространствами имен. Это включает создание набора пространств имен для таких вещей, как классы тем (другими словами, этот класс рестайлинг дочерних элементов для соответствия определенной теме), классы состояний (например, is-active ) и многие другие. В последнее время я видел, как различные разработчики используют пространство имен по-разному, некоторые используют идеи из SMACSS (такие как классы состояния is-active и классы макета для всех контейнеров макета).
Гарри очень хорошо объяснил выгодные отношения между БЭМ и пространством имен. Он сказал: «Я дополняю BEM своим собственным набором пространств имен. Это добавляет целый другой уровень к значимому именованию, которое дает нам БЭМ, сигнализируя о роли класса в не относительных терминах: где БЭМ говорит нам, как классы связаны друг с другом (например, .foo__bar должен жить внутри .foo ), namespacing говорит нам, что класс делает в абсолютном выражении (например, .t-* говорит нам, что этот класс связан с темой) ».
В статье Гарри, описывающей используемые им пространства имен (ту, которую Хэмиш упоминал ранее), содержится более подробная информация, которую можно найти в разделе « Более прозрачный код пользовательского интерфейса с пространствами имен» .
Не бойтесь длинных имен классов
Серж Херкюль также предлагает сосредоточиться на самодокументировании имен классов. Не бойтесь длинных имен классов! Его совет — «Используйте длинные описательные имена классов вместо коротких имен, которые сами не документируются».
Избегайте Sass ‘@extend
Я предоставил разработчикам два разных формата, которые, как я видел, люди используют с BEM, чтобы обдумать, что они используют и почему. Первым был стиль, похожий на объектно-ориентированный CSS:
<div class="block"> <div class="block__element"></div> <div class="block__element"></div> <div class="block__element block__element--modifier"></div> </div>
Вторым был стиль, который использует Sass для обработки наследования:
<div class="block"> <div class="block__element"></div> <div class="block__element"></div> <div class="block__element--modifier"></div> </div>
У меня было единодушное согласие всех разработчиков по этому вопросу. Не используйте @extend где это возможно — используйте первый вариант!
Гарри Робертс рекомендует избегать @extend и вместо этого сохранять стили, определенные внутри классов, в вашей разметке (как в первом примере разметки выше). Его мысли об этом были:
«Вы можете создать большее количество комбинаций в представлении, не« связывая »классы вместе в Sass. HTML имеет гораздо лучший бумажный след в том, что вы можете видеть каждый класс, действующий на части DOM. Ваш CSS остается намного тоньше, так как вам не нужно создавать новые классы-заполнители (или классы манифеста, которые их объединяют) каждый раз, когда вы хотите создать новый элемент пользовательского интерфейса ».
Владимир Старков согласился с тем, чтобы избежать второго варианта, так как это приводит к гораздо большим CSS-файлам. Он предпочитает «декларативный в HTML» с «чистым CSS минимального размера». Он предложил использовать автоматически сгенерированные системы:
«Если вы запутались в классах HTML, которые немного запутаны, вы можете создать их автоматически. Вы можете попробовать kizu / bemto на github для системы шаблонов нефрита и azproduction / b_ на github для любых систем шаблонов на базе nodejs для достижения этой цели автоматизации ».
Боб Дондервинкель также согласился с объектно-ориентированным вариантом:
«Я лично использую объектно-ориентированный подход, потому что он немного более технологичен. Что касается подхода Sass, я фактически пытался сделать вещи еще более «организованными», используя несколько модификаторов в одном имени класса BEM ( https://gist.github.com/BobD/e51edd989e43aaf3d74d ). Но созданный им CSS был довольно ужасным ».
Если вам нужно больше поддержки, чтобы избежать @extend от Sass, Хэмиш Таплин предоставил еще один хороший пример того, почему лучше @extend вещи на несколько классов:
«Я очень рекомендую использовать« мультиклассовый »подход в первом примере вместо« одноклассного »во втором примере. Самая большая проблема с подходом «одного класса» связана с вложением и делает его антишаблоном, на мой взгляд. Рассмотрим следующий пример, в котором мы хотим применить небольшое изменение к .btn внутри .signup-form , делая его полной шириной. Если мы используем мультиклассовый подход к модификаторам, мы можем сделать следующее:
.signup-form { .btn { width: 100%; } }
«Здесь любой экземпляр .btn будет соответствующим образом оформлен в соответствующем контексте. Если мы приняли шаблон для одного класса, а наша .signup-form изменила .btn--blue то наш CSS завершится неудачно, и мы должны добавить каждый тип .btn .btn в наш контекст стиля .signup-form . Это был бы кошмар обслуживания по очевидным причинам! »
Lint ваш CSS!
У Гарри Робертса также есть блестящая система для обеспечения того, чтобы все CSS придерживались правильного соглашения об именах: он выравнивает свой CSS, используя scss-lint, чтобы гарантировать, что все члены команды правильно придерживаются соглашения. Как сказал Гарри, «все хорошо и хорошо говорить команде, что нужно использовать БЭМ, но важно также контролировать это».
Гарри даже написал регулярное выражение для использования с scss-lint, которое работает для определения его стиля классов БЭМ с пространством имен. Вы можете найти это в упомянутой ранее статье « Более прозрачный код пользовательского интерфейса с пространствами имен» .
Выберите инструменты и рабочий процесс, которые лучше всего подходят для вас
Владимир Гриненко из Яндекса стремился указать, что БЭМ может быть больше, чем просто классы CSS. У Яндекса есть целый ряд инструментов, которые дополняют методологию BEM и включают ее в ваш JavaScript и шаблоны.
«Одна из самых важных вещей в методологии BEM заключается в том, что речь идет не только об именах CSS, но и о тех же вещах, что и о веб-компонентах: каждый блок BEM знает все о себе (стили, JS, шаблоны, изображения, тесты, документация, и т.д).
«Мы используем объектно-ориентированный декларативный подход везде: в CSS, JavaScript и шаблонах.
«Кроме того, у нас есть такие мощные концепции, как миксы — когда на одном узле DOM может быть более одного блока BEM: <div class="b1 b2 b3__elem1"></div>. »
Подробнее об инструментах и стеке БЭМ от Яндекса смотрите bem.info .
Как я упоминал выше, многие разработчики, которых я знаю, предпочитают сосредоточиться только на CSS-аспекте BEM. Однако это не означает, что нужно жертвовать возможностью иметь полнофункциональный рабочий процесс. Инструменты Яндекса могут быть полезны для некоторых проектов, но есть альтернативы для тех, кто предпочитает использовать разные рабочие процессы. Яндекс даже проводит семинары, чтобы помочь разработчикам использовать BEM с такими вещами, как Gulp, Angular и другими.
Владимир Старков предпочитает сосредоточиться на методологии CSS и рекомендует найти рабочий процесс, который лучше всего подходит для вашей команды:
«По сути, BEM — это всего лишь методология CSS, а все, что изобретает Яндекс, — это лишь способ упростить совместное использование кода между командами.
«С этой точки зрения хорошо понимать, что вам не нужно использовать полный yandex-bem-стек с bemjson, bh, priv и bem-tools, потому что этот способ очень негибкий и его трудно реализовать в других рабочих процессах.
«Если честно, это была причина, по которой мы создали gulp-bem и getbem.com , мы хотели доставить BEM людям самым простым способом».
Исходя из того, что я получил от наших разработчиков, есть много ресурсов и инструментов, которые помогут вам использовать BEM так, как лучше всего подходит для вашего рабочего процесса. Используйте некоторые аспекты в вашем JavaScript и шаблонизацию, если это работает в вашей команде. Проведите исследование и найдите инструменты, которые подходят вашей команде и проекту. Объедините их. Используйте некоторые из Яндекса и некоторые из других разработчиков. Попробуйте некоторые классные вещи, которые Гарри Робертс начал. Построй свой собственный! Сила твоя. Просто убедитесь, что у вас есть надежный рабочий процесс.
Документация
Один из аспектов ранее высказанного Владимиром Гриненко совета — документация . БЭМ предоставляет большую базу структурированных компонентов (ваших блоков) для документирования и поддержания согласованности на протяжении всего проекта. Если вы сможете сохранить свои названия и структуру на всех уровнях вашего сайта (CSS, JS, HTML-шаблоны и документацию), организованные с помощью компонентов Block, ваш проект станет легче отслеживать и расширять. Объединить это с блестящими концепциями в методологии ITCSS Гарри Роберта и хорошо документированным и структурированным сайтом должно быть немного проще.
Избегайте чрезмерной автоматизации
Я думал, что этот совет от Боба Дондервинкеля был весьма ценным:
«Думаю, что мой главный совет — сохранить BEM CSS переносимым на другие проекты, если это необходимо. Это означает не слишком автоматизировать вещи, поэтому они полезны только в одной среде проекта. Это не значит, что вы в конечном итоге будете использовать этот конкретный фрагмент CSS, но, по крайней мере, это приведет к чистому подходу CSS ».
Все еще не пробовали использовать БЭМ в своей команде?
Для тех, кто еще не сделал скачок, чтобы дать BEM шанс , я решил закончить статью несколькими словами Сержа Геркула о его положительном опыте работы с BEM и Teamweek:
«Изначально у нас не было какой-либо конкретной структуры CSS, и вещи просто начали выходить из-под контроля. Было много вложений Sass, что привело к длинным правилам CSS. Некоторые стили влияли на другие элементы, которые они не должны были и т. Д.
«Переезд в БЭМ был довольно простым процессом, большим количеством ручного труда, но не слишком сложным. В конце концов, я не могу придумать лучшего пути, все проблемы, которые у нас были раньше, ушли ».
Вывод
Я надеюсь, что эта серия интервью дала хороший набор советов и идей для разработчиков, желающих внедрить БЭМ в крупномасштабных проектах (или даже в небольших проектах, которые всегда имеют тенденцию к экспоненциальному росту так, как вы этого меньше всего ожидаете). Если вы ранее не были уверены в использовании BEM в своем следующем проекте, возможно, это даст вам немного больше толчка, чтобы попробовать — преимущества того стоят!
Есть ли у вас какие-либо советы или идеи по использованию БЭМ в масштабе, которые не были охвачены? Не стесняйтесь включать свои мысли в комментариях ниже.