Введение: конец войны методологий

АААААААААААА!!! 15 МИНУТ МОЕЙ ЖИЗНИ ТОЛЬКО ЧТО УШЛИ НА ПРИДУМЫВАНИЕ ИМЕНИ ГРЁБАНОМУ DIV-КОНТЕЙНЕРУ!

Знакомо, да? Не я один, кто неистово бился головой о клавиатуру, пытаясь придумать, как назвать очередную обертку для обертки внутри обертки?

Я УСТАЛ. Мы все устали. Устали от:

• Бесконечного .header__nav-container__menu-wrapper__item-list__element 😵‍💫

• Спора на код-ревью о том, должен ли это быть block__element или просто новый block 🤬

• "Не используй margin на блоке! Это нарушает принципы БЭМ!" — и последующего создания еще одного контейнера 🤦‍♂️

• Конфликтов имён классов в разных компонентах ⚔️

• А потом приходит Tailwind и превращает твой HTML в нечитаемую простыню из 20 классов на элемент 📜

"Я просто хотел сверстать карточку товара, а закончил философским вопросом о природе существования блоков и элементов."

В какой-то момент я понял, что трачу больше времени на придумывание названий классов, чем на написание самого CSS. И подозреваю, что не я один такой.

Но что, если я скажу, что можно прекратить эти мучения?

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

Проблемы чистого БЭМа в реальном мире

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

<!-- Ад нейминга -->
<div class="content-block">
  <div class="content-block__wrapper">
    <div class="content-block__wrapper-inner">
      <div class="content-block__wrapper-inner-container">
        <!-- Наконец-то контент! Осталось только пробраться через эти девять кругов ада нейминга -->
      </div>
    </div>
  </div>
</div>

1. Мучительный нейминг для вспомогательных элементов и контейнеров (Серьезно, кто придумал, что все должно иметь осмысленное имя? Моя кошка и та не страдает, когда я называю её "кис-кис-кис")

2. Проблема с отступами — в чистом БЭМе блок не должен иметь margin, поэтому приходится создавать дополнительные обертки (Потому что, видите ли, margin — это как НЛО: все знают, что они существуют, но никто не признается в их использовании)

3. Раздутая разметка из-за множества уровней вложенности (Ничто так не поднимает самооценку, как ощущение, что ты архитектор, спроектировавший Бурдж-Халифу из div'ов)

4. Сложность переиспользования для позиционирования — приходится создавать множество модификаторов (block_position-top_margin-left_slightly-to-the-right-no-not-that-right-a-bit-more... идеально!)

С другой стороны, чистый Tailwind часто приводит к "салянке" классов, потере семантики и усложнению чтения HTML. (Потому что ничто не говорит "я знаю, что делаю" лучше, чем 42 класса на одном элементе)

Гибридный подход: когда что использовать

1. Используй БЭМ с SCSS и @apply, когда:

• Имеешь дело с семантически очевидными компонентами: .product-card, .user-profile, .catalog (Ключевое слово: "очевидными". Если ты полчаса думаешь, как назвать div, это уже не очевидно, Капитан Очевидность!)

• Работаешь с компонентами с богатой внутренней структурой (Как в большой семье — каждый элемент должен знать своё место и родословную до пятого колена)

• Создаешь переиспользуемые компоненты с разными вариациями (Потому что DRY расшифровывается как "Don't Repeat Yourself", а не "Damn, Repeat Yelp!")

// SCSS с использованием @apply для утилит Tailwind
.product-card {
  @apply bg-white rounded-lg shadow-sm overflow-hidden;
  // 👆 Смотри-ка! Одна строка вместо 10 строк CSS! Какая экономия, прямо как в рекламе стирального порошка!

  &__image {
    @apply w-full object-cover aspect-video;
  }

  &__body {
    @apply p-4;
  }

  &__title {
    @apply text-lg font-medium text-gray-900;
  }

  &__price {
    @apply text-primary-600 font-bold mt-2;
    // Ой, margin-top! Не показывайте это БЭМ-пуристам 🙈

    &_discounted {
      @apply line-through text-gray-400 font-normal;
    }
  }

  // Модификатор для самого блока
  &_featured {
    @apply shadow-md border-2 border-primary-500;
    // А здесь можно было бы создать еще один блок "featured-card",
    // пять оберток и два миксина. Но мы не ищем легких путей, верно?
  }
}

Что дает:

• Четкую структуру компонента (Как государство, но без налогов)

• Легкое переиспользование (Когда-нибудь ваш компонент вырастет и станет библиотекой, и вы будете им гордиться!)

• Хорошую читаемость благодаря SCSS (Потому что нормальные люди не хотят читать CSS, где селекторы длиннее, чем названия лекарств)

• Повторно используемые стили утилит благодаря @apply (Tailwind как пицца — берешь только те кусочки, которые нравятся)

2. Используй чистый Tailwind, когда:

• Работаешь с вспомогательными контейнерами и обертками (Те самые, которым мы всегда даем имена типа wrapper, container, box, и — в момент отчаяния — thingy)

• Создаешь однократные элементы без особой семантики (Потому что не всё заслуживает имени, некоторым достаточно просто быть flex-1 p-4)

• Имеешь сложности с придумыванием осмысленного имени (Когда все хорошие имена уже заняты, а плохие не пропустит код-ревью)

<!-- Вместо мучений с .layout__content-wrapper__inner-container -->
<div class="max-w-screen-xl mx-auto px-4 py-8">
  <div class="grid grid-cols-1 md:grid-cols-3 gap-6">
    <!-- Содержимое, которое не нужно искать в CSS-файлах за тридевять земель -->
  </div>
</div>

Что дает:

• Меньше головной боли с названиями (Потому что "придумывание имен" должно относиться к детям и домашним питомцам, а не к div'ам)

• Быстрая разработка (Ты вернешься домой к ужину, а не будешь до полуночи подбирать имя для очередного элемента)

• Отсутствие дополнительных CSS-файлов для вспомогательных элементов (Меньше файлов = меньше мест, где можно потеряться)

Решение проблемы с margin и позиционированием

Вот где гибридный подход по-настоящему сияет. ✨ Вместо создания модификаторов для каждого варианта отступа и позиционирования (я тебя умоляю, кому нужны .product-card_margin-bottom-16 .product-card_margin-bottom-32 .product-card_margin-left-0-on-mobile?!), используем Tailwind поверх БЭМ-классов:

<!-- Внутренняя структура через БЭМ, позиционирование через Tailwind -->
<article class="product-card mb-4 md:mb-0 md:mr-6 flex-1">
  <img
    class="product-card__image"
    src="product.jpg"
    alt="Product"
  />
  <div class="product-card__body">
    <h3 class="product-card__title">Отличный продукт</h3>
    <div class="flex items-center justify-between mt-3">
      <!-- Да, я использовал флексы внутри БЭМ-блока! Арестуйте меня! -->
      <p class="product-card__price">1999 ₽</p>
      <button class="product-card__button">Купить</button>
    </div>
  </div>
</article>

Обратите внимание:

• product-card и его внутренние элементы следуют БЭМ (Потому что мы воспитанные люди)

• Внешние отступы (mb-4, md:mb-0, md:mr-6) и некоторое позиционирование (flex-1) задаются через Tailwind (Потому что жизнь слишком коротка, чтобы создавать модификаторы для каждого пикселя отступа)

• Для уникальной внутренней структуры, которую сложно выразить в БЭМ, также используем Tailwind (flex items-center justify-between mt-3) (Потому что иногда flex — это просто flex, а не product-card__price-button-row_layout-horizontal)

Переиспользуемые секции: база через БЭМ, вариации через Tailwind

Особенно полезен гибридный подход при работе с секциями сайта, которые переиспользуются в разных контекстах (Ох уж эти секции, которые выглядят одинаково, но дизайнер говорит "здесь отступ должен быть чуть побольше, а здесь — градиент поярче"):

<!-- Базовая структура через БЭМ, специфичные стили через Tailwind -->
<section
  class="hero-section bg-gradient-to-r from-blue-500 to-indigo-600 py-16 md:py-24"
>
  <div class="container mx-auto px-4">
    <h1 class="hero-section__title text-center md:text-left"
      >Заголовок страницы</h1
    >
    <p class="hero-section__subtitle mb-8 max-w-2xl"
      >Подробное описание сервиса</p
    >
    <div class="hero-section__buttons flex flex-col sm:flex-row gap-4">
      <!-- Да, мы используем gap вместо margin между кнопками!
           И нет, нам не стыдно! Это 2023-й, а не каменный век! -->
      <button class="hero-section__button_primary">Начать</button>
      <button class="hero-section__button_secondary">Подробнее</button>
    </div>
  </div>
</section>

.hero-section {
  &__title {
    @apply text-3xl md:text-5xl font-bold text-white;
    // Мама, смотри! Я адаптивную типографику без медиа-запросов сделал!
  }

  &__subtitle {
    @apply text-lg text-white/80;
  }

  &__button {
    &_primary {
      @apply bg-white text-blue-600 font-medium py-3 px-6 rounded-lg;
    }

    &_secondary {
      @apply bg-transparent border-2 border-white text-white py-3 px-6 rounded-lg;
      // 15 строк CSS в одну! Дизайнер даже не заметит подмены!
    }
  }
}

Такой подход позволяет переиспользовать секции, настраивая их внешний вид и позиционирование через Tailwind прямо в месте использования. (А не через 50 модификаторов, имена которых заставляют задуматься о смене профессии)

Работа с компонентами Vue/React/Angular

В мире компонентов гибридный подход тоже прекрасно работает (если ваш тимлид не фанатик какой-то одной методологии):

<!-- ProductCard.vue -->
<template>
  <article
    class="product-card"
  >
    <img
      class="product-card__image"
      :src="product.image"
      :alt="product.name"
    />
    <div class="product-card__body">
      <h3 class="product-card__title">{{ product.name }}</h3>
      <p
        class="product-card__price"
        :class="{ 'product-card__price_discounted': product.hasDiscount }"
      >
        {{ product.price }}
      </p>
    </div>
  </article>
</template>

И используем его так:

<template>
  <div class="grid grid-cols-1 md:grid-cols-3 gap-6">
    <ProductCard
      v-for="product in products"
      :key="product.id"
      :product="product"
      class="mb-4 md:mb-0"
      <!-- Смотрите, никаких custom-component-margin-for-this-specific-case модификаторов! -->
    />
  </div>
</template>

Когда НЕ стоит использовать гибридный подход

1. Микро-проекты — для совсем небольших проектов часто достаточно просто Tailwind (Чтобы потом через 6 месяцев проклинать себя, когда "маленький проект" вырастет в монстра, но кто ж об этом думает в начале?)

2. Строгие требования к методологии — если в команде есть строгие гайдлайны по БЭМ или Tailwind (Или если ваш тимлид носит футболку "БЭМ или смерть")

3. Проекты с устаревшим CSS — может быть сложно интегрировать в унаследованную кодовую базу (Особенно если там есть !important в каждой второй строке и inline-стили "потому что так быстрее")

Заключение

Гибридный подход БЭМ + Tailwind это не ересь (хотя пуристы с обеих сторон могут сжечь вас на костре), а прагматичное решение реальных проблем:

• Перестаем мучиться с неймингом вспомогательных элементов (Нет больше "как назвать этот div, который просто центрирует контент?")

• Решаем проблему с отступами и позиционированием (Потому что отступы — это отношения между элементами, а не их внутреннее дело!)

• Сохраняем семантическую структуру для сложных компонентов (Чтобы разобраться даже спустя год)

• Ускоряем разработку благодаря утилитам (И успеваем закончить до дедлайна, что уже чудо)

Личный опыт: спасение из CSS-ада

Знаете, я ведь не просто так все это пишу. Я лично использовал этот подход на реальном коммерческом проекте, когда уже был готов наплевать на все методологии и начать писать стили прямо в атрибутах (да, было настолько х**во).

Когда мой проект вырос до 30+ компонентов, я начал замечать, что:

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

2. Каждый новый элемент вызывал приступ экзистенциального кризиса: "это новый бл**ь блок или элемент существующего блока?"

3. Меня начинало потряхивать от необходимости создавать очередной модификатор типа block__element_margin-bottom-md

И тут меня осенило. Если я использую БЭМ для чётких семантических блоков, а Tailwind — для всего остального, жизнь становится прекрасной! Разработка ускорилась примерно в два раза. Я перестал тратить время на бессмысленные споры с самим собой о том, как назвать очередной ёб**ый контейнер, который просто центрирует содержимое.

После перехода на гибридный подход:

• Верстать стало удовольствием, а не пыткой

• Компоненты действительно стали переиспользуемыми без тонны модификаторов

• Код-ревью перестали превращаться в лекции по правильному именованию в БЭМ

• Дизайнер перестал закатывать глаза, когда я говорил, что внести "небольшие изменения в отступы" займёт полдня

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

Не нужно быть религиозным фанатиком одной методологии — вместо этого используйте лучший инструмент для конкретной задачи. Иногда это БЭМ, иногда Tailwind, а часто — их разумное сочетание. Я за**ался тратить время на споры о методологиях, когда можно просто делать крутой продукт!