Можливо прийшов час перестати використовувати БЕМ ?

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Років 7 тому, коли я ще тільки починав ( а може і навіть раніше! ); усі стилі були в одному великому файлі, а класам давали будь-які назви без чіткої системи. У великих проєктах це неминуче призводило до конфліктів і переписування стилів. Щоб розв’язати цю проблему, хтось там придумав методологію BEM, яка чітко регламентувала іменування класів та структуру CSS.

Як взагалі це працює BEM?

1. Блок (Block) — основна незалежна частина інтерфейсу, наприклад, кнопка (button) або меню (menu).
2. Елемент (Element) — складова блоку, яка не може існувати окремо від нього, наприклад, іконка чи текст усередині кнопки. Їх пишуть у форматі block__element.
3. Модифікатор (Modifier) — варіація блоку або елемента. Зазвичай використовується, щоб змінити стиль чи стан, наприклад колір кнопки. У записі має вигляд block--modifier

Приклад

<div class="button button--primary">
  <span class="button__icon">+</span>
  <span class="button__text">Додати</span>
</div>

• button — це блок
• button__icon, button__text — елементи
• button—primary — модифікатор для стилю кнопки

BEM швидко набув популярності, тому що допомагав організувати CSS у масштабних проєктах. Але в міру зростання проєктів, методологія виявила кілька незручностей:

1. Довгі та складні імена класів. Якщо є багато елементів або модифікаторів, назви можуть ставати довжелезними, що ускладнює читання коду.
2. Складність у рефакторингу. Зміни в дизайні означають зміну безлічі класів у HTML, що доволі виснажливо.
3. Глобальний простір імен. Хоча BEM іменує класи структуровано, зрештою все одно всі стилі зберігаються глобально, і можливі неочікувані конфлікти, якщо назви збігаються.
4. Все вручну. Точне дотримання BEM вимагає уважності від кожного розробника в команді. Будь-яка дрібна помилка в іменуванні може викликати плутанину.

Чому сьогодні можна задуматись на тим щоб відмовитись від BEM ?

Я побачив нещодавно проект на Vue де якраз використовують BEM, і в мене одразу в голові виникло, а навіщо, якщо сучасні фреймворки (React, Vue, Svelte, Angular) орієнтовані на компонентний підхід. У них:

• в React — CSS Modules чи Styled Components, автоматично створюють унікальні назви класів для компонентів.
• Vue — в компоненті можна визначити стилі в <style scoped>, і вони діятимуть лише в межах цього компонента.
• у Svelte — усі стилі в компоненті належать тільки цьому компоненту; унікальні класи додаються на етапі компіляції.
• Angular — технологія ViewEncapsulation ізолює стилі кожного компонента від решти додатка.

Завдяки цим рішенням автоматичний неймспейсинг став звичною справою, і немає потреби керувати класами вручну, як це робить BEM. У результаті ми отримуємо код, який простіше підтримувати, а ризик конфліктів зводиться до мінімуму.

У підсумку виходить таке:

• BEM свого часу дуже допоміг впорядкувати CSS, але зараз на зміну йому прийшли фреймворки та інструменти, що дають автоматичне групування й захист стилів.
• Якщо ви тільки вчитеся верстати, корисно знати, що таке BEM, адже це чудовий спосіб організувати код.
• В сучасних умовах компонентний підхід виконує роботу BEM автоматично, тому в багатьох проєктах від нього поступово відмовляються.