Как принять TailwindCSS и начать жить
В одной из прошлых статей я упомянул, что я делал лендинг codly.cc. Я долго думал, попробовать ли TailwindCSS или нет. Этот CSS-фреймворк уже достаточно давно на слуху, но у меня так и не было возможности попробовать его. Сегодня хочу поделиться своими мыслями об этом инструменте — осветить его сильные и слабые стороны.
TL;DR: Основное преимущество TailwindCSS — улучшение стандартизации стилей с помощью готовой модульной сетки, палитры цветов и прочих заранее заданных настроек.
Особенно это ценно в командах без отдельного дизайнера, так как минимизирует риски выбора неправильных размеров элементов и отступов. Из-за этого верстка получается более опрятная без дополнительных усилий.
Этапы знакомства с Tailwind
Некоторые разработчики при первом знакомстве с TailwindCSS проходят несколько этапов (вроде известных пяти стадий принятия).
Я не оказался исключением. Однако, я не придумал как это сопоставить с пятью этапами, поэтому ограничимся тремя:
Этап 1 — Отрицание
Когда впервые видишь код верстки с применением TailwindCSS, возникает естественное непонимание. Зачем захламлять шаблон кучей сложночитаемых CSS-классов, по сути изобретая новый язык? Почему нельзя просто писать стили напрямую в CSS?
Два принципиальных преимущества Tailwind становятся очевидны только со временем:
- Отсутствие необходимости переключаться между HTML и CSS-файлами позволяет экономить время и фокус внимания, но заметно это становится на долгой дистанции
- Свойства легче описывать, т.к. из названия банально короче
На первый взгляд эти два пункта кажутся мелочью: ну и что такого, не сложно же переключаться 100 раз между файлами за одну рабочую сессию. Да и писать «bg» вместо «background» — не намного короче…
если бы это было один раз.
Однако реальный выигрыш TailwindCSS проявляется при быстром прототипировании«с нуля». Забавно, но до знакомства с Tailwind я всерьез задумывался о библиотеках готовых компонентов вроде Bootstrap — даже для простых кнопок.
После того, как я поработал с Tailwind оказалось, что создавать такие компоненты достаточно просто даже на этапе раннего прототипирования. Особенно сейчас, когда доступны ИИ ассистенты для автоматического написания кода.
Этап 2 — Торг
Хорошо. Допустим, Tailwind действительно повышает продуктивность. Но что делать с таким большим количеством классов, которые раздувают объем кода? Вместо уникальных классов для компонентов мы используем множество идентичных стилевых классов. Ведь это выглядит как прямое нарушение принципа DRY (Don't Repeat Yourself).
Получается фреймворк заставляет нас нарушать лучшие практики?!
С одной стороны выходит так, но с другой — нам, наоборот, не нужно повторять правила CSS, а только классы.
Грань становится довольно размыта...
Второй аргумент против TailwindCSS — громоздкий HTML код из-за большого количества классов. Да, это действительно так, вот пример карточки кода для карточки поста со страницы, которую я верстал:
Однако у Tailwind есть встроенное решение — директива @apply, которая позволяет группировать модификаторы в один CSS-класс.
То есть мы можем использовать компонентные классы как и прежде, а иногда и вообще обходится без классов, используя жесткую структуру вложенности HTML. Тогда можно вынести классы TailwindCSS в отдельный файл со следующими селекторами:
Так код выглядит значительно более компактно, не уступая обычным подходам к верстке:
Единственный ньанс здесь — это классы group и group-hover. Они обязательно должны находиться в HTML, иначе TailwindCSS не сможет их распознать. Но для справедливости надо сказать, что этот функционал не стандартный и его можно не использовать.
Этап 3 — Принятие
В результате получается, что грамотное комбинирование собственных классов с возможностями TailwindCSS позволяет осуществлять быстрое прототипирование прямо в HTML. А уже после формирования компонента, его можно вынести в отдельные CSS-классы. Благодаря этому получается совместить лучшие стороны обоих подходов.
Главное преимущество для меня как для разработчика — отсутствие необходимости самостоятельно вычислять закономерности для отступов, размеров шрифта, задавать точки для мобильной и десктопной версии. Более того, не нужно даже подбирать цвета — TailwindCSS предлагает обширную встроенную палитру, которую можно расширять или заменить на свою.
Заключение
Сложно предельно точно объяснить разницу между TailwindCSS и другими CSS-фреймворками вроде Bootstrap. Но она действительно существует: если классические библиотеки задают жесткие рамки, то Tailwind дает максимальный простор для творчества.
Возможно, поэтому проекты на Bootstrap часто выглядят очень похоже друг на друга, а сайты на TailwindCSS — практически уникальны. Единственное, что их объединяет — модульная сетка и, возможно, цветовая палитра. Можете убедиться сами, вот некоторые сайты, которые используют TailwindCSS:
Можно сказать, что TailwindCSS — это не просто инструмент, это больше похоже на другую философию современной веб-разработки. И хотя как и любого инструмента у него есть свои достоинства и недостатки, он позволяет создавать по-настоящему уникальные проекты. Каждый из примеров выше не похож друг на друга, хотя использует один и тот же фреймворк.
Поэтому если вы задумывались о том, стоит ли попробовать TailwindCSS, то я вам отвечу: стоит, но нужно быть готовым к тому, что в начале это может оказаться неудобно и нужно будет потратить некоторое время, чтобы привыкнуть.
Такая цена пользования любого нового инструмента.
Если вам понравилась эта статья, буду благодарен, если поставите лайк 🔥 и напишите комментарий — так я пойму, что на подобные темы стоит писать больше.
Также я веду свой Telegram-блог «Код без тайн», в котором пишу о веб-разработке, информатике и других технологиях: