Как принять TailwindCSS и начать жить

На момент написания этой статьи, актуальная версия — 3.4 / <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Ftailwindcss.com%2Fblog%2Ftailwindcss-v3-4&postId=1687597" rel="nofollow noreferrer noopener" target="_blank">TailwindCSS</a>
На момент написания этой статьи, актуальная версия — 3.4 / TailwindCSS

В одной из прошлых статей я упомянул, что я делал лендинг codly.cc. Я долго думал, попробовать ли TailwindCSS или нет. Этот CSS-фреймворк уже достаточно давно на слуху, но у меня так и не было возможности попробовать его. Сегодня хочу поделиться своими мыслями об этом инструменте — осветить его сильные и слабые стороны.

TL;DR: Основное преимущество TailwindCSS — улучшение стандартизации стилей с помощью готовой модульной сетки, палитры цветов и прочих заранее заданных настроек.

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

Этапы знакомства с Tailwind

Некоторые разработчики при первом знакомстве с TailwindCSS проходят несколько этапов (вроде известных пяти стадий принятия).
Я не оказался исключением. Однако, я не придумал как это сопоставить с пятью этапами, поэтому ограничимся тремя:

Три этапа принятия TailwindCSS<br />
Три этапа принятия TailwindCSS

Этап 1 — Отрицание

Когда впервые видишь код верстки с применением TailwindCSS, возникает естественное непонимание. Зачем захламлять шаблон кучей сложночитаемых CSS-классов, по сути изобретая новый язык? Почему нельзя просто писать стили напрямую в CSS?

Два принципиальных преимущества Tailwind становятся очевидны только со временем:

  1. Отсутствие необходимости переключаться между HTML и CSS-файлами позволяет экономить время и фокус внимания, но заметно это становится на долгой дистанции
  2. Свойства легче описывать, т.к. из названия банально короче

На первый взгляд эти два пункта кажутся мелочью: ну и что такого, не сложно же переключаться 100 раз между файлами за одну рабочую сессию. Да и писать «bg» вместо «background» — не намного короче…
если бы это было один раз.

Однако реальный выигрыш TailwindCSS проявляется при быстром прототипировании«с нуля». Забавно, но до знакомства с Tailwind я всерьез задумывался о библиотеках готовых компонентов вроде Bootstrap — даже для простых кнопок.

После того, как я поработал с Tailwind оказалось, что создавать такие компоненты достаточно просто даже на этапе раннего прототипирования. Особенно сейчас, когда доступны ИИ ассистенты для автоматического написания кода.

Этап 2 — Торг

Хорошо. Допустим, Tailwind действительно повышает продуктивность. Но что делать с таким большим количеством классов, которые раздувают объем кода? Вместо уникальных классов для компонентов мы используем множество идентичных стилевых классов. Ведь это выглядит как прямое нарушение принципа DRY (Don't Repeat Yourself).

Получается фреймворк заставляет нас нарушать лучшие практики?!

С одной стороны выходит так, но с другой — нам, наоборот, не нужно повторять правила CSS, а только классы.

Грань становится довольно размыта...

В любом проекте появляются CSS классы утилиты. Так ли плох TailwindCSS? Источник: <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fcleancommit.io%2Fblog%2Fwhy-we-use-tailwind-css-as-our-primary-framework%2F&postId=1687597" rel="nofollow noreferrer noopener" target="_blank">Wojciech Kałużny</a>
В любом проекте появляются CSS классы утилиты. Так ли плох TailwindCSS? Источник: Wojciech Kałużny

Второй аргумент против TailwindCSS — громоздкий HTML код из-за большого количества классов. Да, это действительно так, вот пример карточки кода для карточки поста со страницы, которую я верстал:

<a href="#" class="js-card-template group hidden w-full flex-col overflow-hidden rounded-lg border border-slate-100 bg-white shadow-sm duration-100 hover:-translate-y-1 hover:shadow-lg lg:w-1/3" > <div class="flex h-full flex-col"> <img class="js-card-image aspect-video w-full scale-[1.06] rounded-t-lg object-cover" /> <div class="relative flex flex-1 flex-col p-6 pb-0"> <h3 class="pb-3 text-lg font-medium text-slate-900"> <span class="js-card-title">Название</span> </h3> <p class="flex-1 text-sm leading-relaxed text-slate-600"> <span class="js-card-description">Описание</span> </p> </div> <div class="items-center justify-self-end bg-slate-50 py-2 text-center opacity-0 duration-100 group-hover:opacity-100" > <span class="text-sm text-slate-900">Читать далее →</span> </div> </div> </a>

Однако у Tailwind есть встроенное решение — директива @apply, которая позволяет группировать модификаторы в один CSS-класс.
То есть мы можем использовать компонентные классы как и прежде, а иногда и вообще обходится без классов, используя жесткую структуру вложенности HTML. Тогда можно вынести классы TailwindCSS в отдельный файл со следующими селекторами:

.cards .card { @apply ... } .cards .card > div { @apply ... } .cards .card > div > img { @apply ... } .cards .card > div > .description { @apply ... } .cards .card > div > .description > h3 { @apply ... } .cards .card > div > .description > p { @apply ... } .cards .card > div > .read-more { @apply ... } .cards .card > div > .read-more > span { @apply ... }

Так код выглядит значительно более компактно, не уступая обычным подходам к верстке:

<a href="#" class="js-card-template card group hidden"> <div> <img class="js-card-image" /> <div class="description"> <h3> <span class="js-card-title">Название</span> </h3> <p> <span class="js-card-description">Описание</span> </p> </div> <div class="read-more group-hover:!opacity-100"> <span>Читать далее →</span> </div> </div> </a>

Единственный ньанс здесь — это классы group и group-hover. Они обязательно должны находиться в HTML, иначе TailwindCSS не сможет их распознать. Но для справедливости надо сказать, что этот функционал не стандартный и его можно не использовать.

Этап 3 — Принятие

В результате получается, что грамотное комбинирование собственных классов с возможностями TailwindCSS позволяет осуществлять быстрое прототипирование прямо в HTML. А уже после формирования компонента, его можно вынести в отдельные CSS-классы. Благодаря этому получается совместить лучшие стороны обоих подходов.

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

Заключение

Сложно предельно точно объяснить разницу между TailwindCSS и другими CSS-фреймворками вроде Bootstrap. Но она действительно существует: если классические библиотеки задают жесткие рамки, то Tailwind дает максимальный простор для творчества.

Возможно, поэтому проекты на Bootstrap часто выглядят очень похоже друг на друга, а сайты на TailwindCSS — практически уникальны. Единственное, что их объединяет — модульная сетка и, возможно, цветовая палитра. Можете убедиться сами, вот некоторые сайты, которые используют TailwindCSS:

Можно сказать, что TailwindCSS — это не просто инструмент, это больше похоже на другую философию современной веб-разработки. И хотя как и любого инструмента у него есть свои достоинства и недостатки, он позволяет создавать по-настоящему уникальные проекты. Каждый из примеров выше не похож друг на друга, хотя использует один и тот же фреймворк.

Поэтому если вы задумывались о том, стоит ли попробовать TailwindCSS, то я вам отвечу: стоит, но нужно быть готовым к тому, что в начале это может оказаться неудобно и нужно будет потратить некоторое время, чтобы привыкнуть.

Такая цена пользования любого нового инструмента.

Если вам понравилась эта статья, буду благодарен, если поставите лайк 🔥 и напишите комментарий — так я пойму, что на подобные темы стоит писать больше.

Также я веду свой Telegram-блог «Код без тайн», в котором пишу о веб-разработке, информатике и других технологиях:

3
Начать дискуссию