Tailwind против обычного CSS: когда что выбирать

У вас проект, где нужно верстать много однотипных экранов — карточки, формы, таблицы. Классический CSS требует придумывать имена классов, держать в голове структуру файлов и бороться с каскадом. Tailwind предлагает не писать CSS вообще, а собирать стиль из готовых утилит прямо в разметке. Оба подхода решают одну задачу — оформить интерфейс — но платите вы за них по-разному: временем, размером бандла, читаемостью HTML и сложностью поддержки. Разберём, где что выбрать, на примере Tailwind 3.x (в 4.x поменялась конфигурация, но логика сравнения та же).

В чём разница на практике

Обычный CSS — вы пишете селектор и правила отдельно от разметки:

/* styles.css */
.card {
  padding: 1rem;
  border-radius: 0.5rem;
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
}

<div class="card">...</div>

Tailwind — вы навешиваете готовые утилиты, каждая из которых отвечает за одно свойство:

<div class="p-4 rounded-lg shadow">...</div>

Разница не только в синтаксисе. В первом случае имя card — это уровень абстракции: вы решаете, что такое «карточка», и меняете её вид в одном месте. Во втором абстракции нет — есть набор конкретных свойств прямо в HTML. Это и главный плюс Tailwind (не нужно придумывать имена и прыгать между файлами), и главный его минус (нет единой точки правки, разметка распухает).

Что выигрываете и чем платите

Tailwind ускоряет старт и убирает целый класс проблем — но не бесплатно. Обычный CSS даёт контроль и чистую разметку — но требует дисциплины именования.

• Tailwind, плюс: нет мёртвого CSS. Финальный бандл содержит только те утилиты, что реально встретились в разметке — сборщик вырезает остальное сканированием файлов¹. На среднем проекте это десятки килобайт вместо разрастающегося годами CSS-файла.
• Tailwind, минус: разметка становится длинной. Кнопка с ховером, фокусом и адаптивом легко набирает 10–15 классов в одну строку. Читать diff в такой строке тяжело.
• Обычный CSS, плюс: HTML остаётся семантичным и коротким, а логику оформления видно целиком в одном файле.
• Обычный CSS, минус: каскад и глобальная область видимости. Класс .title, объявленный в двух местах, тихо переопределяет сам себя, и вы ищете, откуда прилетел лишний margin.

Дубли — общая боль обоих

В Tailwind повторяющийся набор утилит превращается в копипасту: одна и та же длинная строка классов на десяти кнопках. Решение — вынести компонент (в React/Vue) или использовать директиву @apply в CSS-слое, но @apply частично возвращает вас к обычному CSS со всеми его именами. В классическом CSS дубли решаются переменными и общими классами, но появляется противоположная проблема — глобальные имена начинают конфликтовать.

Tailwind не отменяет CSS — он переносит сложность из файла стилей в разметку. Вопрос не «что лучше», а «где вам удобнее держать эту сложность».

Таблица сравнения

Когда что выбирать

Критерий не в размере проекта, а в характере интерфейса и в том, как устроена команда.

• Берите Tailwind, если интерфейс состоит из типовых блоков (админки, дашборды, лендинги на компонентах), вы работаете во фреймворке с компонентами (React, Vue, Svelte), где дубли выносятся в один файл, и в команде нет выделенного верстальщика — фронтендеры хотят не переключаться между HTML и CSS.
• Берите обычный CSS, если у вас уникальный дизайн со сложной анимацией и нестандартной сеткой, важна семантика и чистота разметки (например, крупный публичный сайт с упором на доступность), или в команде есть верстальщик, который мыслит категориями CSS-архитектуры (BEM, слои).
• Смешанный вариант: Tailwind для быстрой раскладки и отступов плюс обычный CSS-модуль для сложных уникальных компонентов — рабочая практика, если не превращать её в хаос из двух конкурирующих систем.

Что ломается на практике

Оба подхода дают предсказуемые грабли — их лучше знать заранее.

• Tailwind: динамические классы не собираются. Сканер ищет полные строки классов в исходниках. Конструкция вида bg-${color}-500 в JS не попадёт в бандл, потому что такой строки в коде нет целиком. Держите полные имена классов или заносите варианты в safelist через конфиг.
• Tailwind: arbitrary-values как соблазн. Записи вроде mt-[13px] ломают идею дизайн-токенов. Одна-две такие — нормально, но если их десятки, вы фактически пишете инлайн-стили и теряете смысл системы отступов.
• Обычный CSS: рост специфичности. Чтобы перебить чужое правило, добавляют ещё один селектор, потом ещё — и вы приходите к !important. Это симптом, что архитектура стилей поплыла.
• Обычный CSS: мёртвые правила. Классы, которые давно никто не использует, остаются в файле. Без автоматической проверки их не отличить от живых, и файл только растёт.

Что делать дальше

Если решили пробовать Tailwind — не оценивайте его на одном экране кнопки. Соберите на нём типовой кусок проекта целиком (форму, список, модалку) и посмотрите на diff и на то, как выносятся дубли в вашем фреймворке. Настройте content-пути в конфиге правильно с первого раза — от этого зависит, что попадёт в бандл, а что вырежется. Если остаётесь на обычном CSS, введите методологию именования (BEM или CSS-модули) до того, как файл разрастётся, и подключите линтер стилей, чтобы ловить дубли и рост специфичности. Мерить стоит не «нравится/не нравится», а размер итогового CSS и скорость правки типовой задачи в вашей команде.

¹ Purge/content-сканирование — механизм, при котором сборщик читает указанные файлы разметки, находит использованные классы и оставляет в финальном CSS только их. Всё, что не встретилось в коде, в бандл не попадает.