Очевидно, я бы не стал писать эту статью, если бы считал, что TailwindCSS просто очередной фреймворк. Я считаю, что он кардинально отличается от всех других фреймворков и создает отдельную парадигму web-стилизации. И при этом выполняет все поставленные перед ним задачи, делая это лучше и удобнее других.

Тех, кто еще не знаком с TailwindCSS, я постараюсь завербовать в ряды его поклонников. Тех, кто против него, я постараюсь заставить в этом усомнится и пересмотреть своё мнение.

Я также хотел узнать ваше мнение по этому поводу. TailwindCSS это шаг вперед, назад или просто топтание на месте? Свой ответ вы можете оставить в опросе в конце статьи. А если вам есть, что добавить по теме, пожалуйста, сделайте это в комментариях.

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

По факту, вы пишете свой CSS как HTML-классы в формате похожем на популярный плагин Emmet. Ерунда? Как бы не так. Всё дело как всегда в деталях и окружении.

Я прекрасно понимаю людей, которые морщатся при виде такого формата записи. И я понимаю почему. Но мне кажется, что это просто плохая привычка из "программистского детства".

Мы попробуем избавится от неё и понять все плюсы работы с TailwindCSS. Для этого сначала перечислим все минусы, которые якобы свойственны таким CSS-фреймворкам. А затем разберемся, есть ли они в TailwindCSS.

Проблемы

1. Как бы много не было классов, мы всё равно ограничены данным нам набором. Мы загоняем своё оформление в придуманные за нас рамки, что приводит к тому, что все сайты, написанные на TailwindCSS похожи друг на друга.
2. У нас будет куча лишних стилей, которые мы не используем.
3. Если нам нужно сделать две одинаковых кнопки, нам придется еще раз писать те же самые классы в другом месте.
4. Засорять HTML стилями это строго против правил. Всех верстальщиков "с пелёнок" учат не писать стили inline, а TailwindCSS нарушает эту аксиому.

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

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

1. TailwindCSS это не Bootstrap

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

Если вы считаете, что TailwindCSS лишает сайты оригинальности, значит вы эту разницу пока не видите. Во-первых, претензия к одинаковости касается именно Bootstrap и подобных фреймворков с классами как компонентами. Во-вторых, даже там при желании всё можно кастомизировать до неузнаваемости, переписав классы под свои нужды и разбавив с классами из чистого CSS.

В чем основная сила Bootstrap он хорошо подходит для proof of concept. Быстро нарисовать более-менее красивый интерфейс, когда нужно показать функционал, это Bootstrap. Нам не столь важен внешний вид, главное, чтобы быстро и глаза не резало (например, в админпанели), это тоже Bootstrap.

TailwindCSS в таких случаях не подходит по определению. У вас нет готовых компонентов, вам всё нужно писать с нуля (TailwindUI не в счет).

Конечно, TailwindCSS изначально тоже вас ограничивает. Например, есть margin со значением 2.5rem, есть 3rem, но нет 2.75rem. Ограничение. Однако оно легко решается настройками в файле tailwind.config.js, где вы можете добавить любые значения, нужные вам в проекте.

Вы можете добавлять, удалять и переписывать любые классы. Если вдруг вас не устраивает цвет bg-red-500, вы можете его изменить одной строчкой кода. В других фреймворках вам бы пришлось менять компоненты. Подробнее о кастомизации читайте в документации.

2. Никаких лишних стилей

Проблема с переизбытком лишних классов также решается с помощью tailwind.config.js. Если раньше вам нужно было добавлять PurgeCSS или другую библиотеку для удаления лишних классов, теперь TailwindCSS сделает это за вас. Всё, что вам нужно сделать, указать папку, где хранятся ваши файлы с разметкой. TailwindCSS сам пройдется по ним, найдет все использованные классы, их оставит, а остальные удалит.

Если какие-то классы добавляются через JavaScript, укажите их в whitelist, TailwindCSS также их сохранит. Подробнее в документации.

3. Переиспользуемость

Если писать CSS в inline-стиле, для одинаковых или почти одинаковых кнопок каждый раз придется писать почти один и тот же код. Как эту проблему можно решить в TailwindCSS? It depends.

Если вы пишете код без фронтенд-фреймворка, ваш выбор очевиден это директива @apply.

У вас есть кнопка

<button class="px-4 py-2 font-bold text-white bg-blue-500 rounded">Отправить</button>

И тут вам нужно использовать её где-то еще. Можно просто скопировать эту кнопку и вставить HTML-код в другое место. А можно открыть main.css файл и скопировать TailwindCSS-классы туда в отдельный CSS-класс.

@tailwind base;@tailwind components;.btn {  @apply bg-blue-500 text-white font-bold py-2 px-4 rounded;}@tailwind utilities;

Теперь мы можем просто добавить btn как обычный CSS-класс в HTML и переиспользовать сколько угодно раз. При этом мы можем как-угодно кастомизировать нашу кнопку, просто добавляя TailwindCSS-классы.

<button class="btn">Отправить</button><button class="btn px-6 py-4 bg-red-500">Отправить</button>

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

Если же модифицированная кнопка используется не в одном месте, а в множестве, можно сделать модификатор. TailwindCSS вас в этом не ограничивает, но и не заставляет. При желании можно создать отдельный класс, и уже писать btn btn-red. Подробнее в документации.

Если вы используете любой фронтенд-фреймворк, у вас вообще нет данной проблемы. Вам не нужна директива @apply. Вы просто делаете отдельный компонент для любого повторяющегося кода. Легко и удобно.

Для примера воспользуемся самым простым из возможных вариантов Alpine.js.

<div x-data="cards()" class="space-y-12">  <template x-for="card in cards">    <div>      <img class="rounded" :src="card.img" :alt="card.imgAlt" />      <div class="mt-2">        <div x-text="card.eyebrow" class="text-xs font-bold text-gray-600 uppercase"></div>        <div class="font-bold leading-snug text-gray-700">          <a x-text="card.title" :href="card.url" class="hover:underline"></a>        </div>      </div>    </div>  </template></div><script>  // ...</script>

Даже если вы не планировали использовать фреймворк, 7 килобайт, которые вы потратите на Alpine.js, быстро окупятся. Подробнее об Alpine.js в других моих статьях.

А если вы вместо Alpine.js используете полноценный компонентный фреймворк (React, Vue и др.), это становится еще проще. Вы просто добавляете <MyComponent>, где внутри скрыта вся логика.

4. Писать стили в HTML это не плохо

Как ни крути, последнюю проблему невозможно решить. Потому что здесь это основная фича. Менять нужно не фреймворк, менять нужно отношение к нему.

Большую часть истории Web писать стили в HTML-коде было моветоном. Использовать тег style было жутко неудобно, всё превращалось в жуткую колбасу, которую было невозможно разобрать. К тому же, некоторый новый функционал, например media-запросы (в TailwindCSS они есть как приставки sm:, md:), в нем просто не поддерживались. Отформатированный CSS было элементарно удобнее.

Когда появился Bootstrap, весь предыдущий негативный опыт отразился на отношении сообщества к такому подходу. И он сохранился до сих пор, хотя объективных причин для этого нет.

При правильной реализации, описывать стилизацию вместе с разметкой оказывается невероятно удобно. Удобно видеть HTML-элемент и сразу понимать, как он стилизован. Удобно писать верстку, не перескакивая из файла в файл. Если вы писали на Vue или на Svelte, вы знаете, о чем это я.

Заключение

Так какое же место занимает TailwindCSS в истории CSS?

Он удобнее ванильного CSS и не создает проблем со вложенностью и коллизией имен классов.

Он отлично работает со всеми препроцессорами. Поэтому, если вам нужно построить базу стилей с переменными, прогнать цикл и т.п., TailwindCSS этому никак не мешает.

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

С TailwindCSS пограничные случаи не будут занимать отдельный класс. Можно вообще весь код писать без самописных классов. Так решается проблема, для которой были придуманы CSS-модули.

Мне нравится формат работы со стилями, который мне предлагает этот фреймворк. Но каждый должен попробовать и решить это для себя самого. Мне рекомендовали TailwindCSS со словами: "Попробуй, потом не захочешь делать по другому". Я попробовал, и теперь мне не хочется делать по другому. Попробуйте и вы.

Напоследок один небольшой лайфхак, который показывает еще одну удобную функцию TailwindCSS: с ним стили можно очень удобно править прямо в Chrome DevTools.



Выбираем элемент, в панели нажимаем .cls, пишем классы, а затем просто копируем их к себе в верстку.