Tailwindcss

Современные фронтенд-фреймворки дают удивительные возможности. React, Vue, Angular и другие созданы делать то, что раньше было невозможно, веб-приложения. В 2020 скачивать и устанавливать приложения уже необязательно. Зачем, если всё можно сделать на сайте?

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

В этом вопросе я поддерживаю "консерваторов". Не нужно писать лендинги и многостранички на Create-React-App, для этого пойдет и обычная статика.

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

Что делать? Писать простыню HTML-разметки в одном файле? Хранить данные во view? Это не сделать шаг назад, это сорваться и упасть в пропасть. Это не просто неудобно, это идет вразрез с современной парадигмой фронтенд-разработки.

Во-первых, data-driven. Данные во главе угла, а внешний вид лишь их отображение. Пользователь делает действие, данные меняются, вслед меняется отображение. Так работают все современные фреймворки.

Еще один элемент современного подхода компонентность. Делим приложение на мелкие самодостаточные переиспользуемые куски. Больше переиспользуемости меньше кода. Меньше кода меньше багов.

До этого мы уже обсуждали, как реализовать data-driven минимальными усилиями. Мой выбор Alpine.js. Что же делать с компонентностью? Для простых статических сайтов я предлагаю самый простой вариант gulp-file-include.

Столько говорил о современности и парадигмах, а закончилось всё библиотекой, которой уже лет 100? Ну, на самом деле, она не такая уж и старая. 4 года с версии 1.0.0, столько же, сколько первой стабильной версии React (15). Да и зачем заново изобретать велосипед, если уже всего готово.

У библиотеки всего шестьсот звезд на Github и 6,5 тысяч скачиваний в неделю на npm, но она дает нам всё, что нужно, чтобы быстро разделить простыню HTML на небольшие удобные компоненты. И при этом не добавив ни байта дополнительного кода в конечный результат.

Единственная преграда знакомство с Gulp. Ну, на самом деле, писать даже простой лендинг без подобного инструмента сегодня не очень правильно. Поэтому, если вы не знаете Gulp, узнайте. Вот для этого статья на Хабре, вот ссылка на перевод документации. Мы на этом останавливаться не будем.

Если вы хотите не прерываться, а хотите продолжить со мной, вот ссылка на мой пресет на Github, с которым мы будем работать, там же вы можете найти мой gulpfile.

Итак, что будем делать? Вот это

Выглядит просто. Посмотрим, как это выглядит в HTML.

<section class="text-gray-700 body-font">  <div class="container px-5 py-24 mx-auto">    <h1 class="mb-20 text-2xl font-medium text-center text-gray-900 sm:text-3xl title-font">      Проблемы, которые я решаю    </h1>    <div class="flex flex-wrap -mx-4 -mt-4 -mb-10 sm:-m-4 md:mb-10">      <div        class="flex flex-col items-center p-4 mb-6 sm:flex-row lg:w-1/3 md:mb-0 sm:items-stretch"      >        <div          class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"        >          <svg            class="w-6 h-6"            fill="none"            stroke="currentColor"            stroke-linecap="round"            stroke-linejoin="round"            stroke-width="2"            viewBox="0 0 24 24"          >            <path d="M22 12h-4l-3 9L9 3l-3 9H2"></path>          </svg>        </div>        <div class="flex-grow pl-6">          <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">Оптимизация скорости</h2>          <p class="text-lg leading-relaxed">            Увеличим быстродействие системы при загрузке, уменьшим нагрузку на процессор и оперативную память, исключим из автозагрузки требовательные к ресурсам устройства программы.          </p>        </div>      </div>      <div        class="flex flex-col items-center p-4 mb-6 lg:w-1/3 md:mb-0 sm:flex-row sm:items-stretch"      >        <div          class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"        >          <svg            class="w-6 h-6"            fill="none"            stroke="currentColor"            stroke-linecap="round"            stroke-linejoin="round"            stroke-width="2"            viewBox="0 0 24 24"          >            <circle cx="6" cy="6" r="3"></circle>            <circle cx="6" cy="18" r="3"></circle>            <path d="M20 4L8.12 15.88M14.47 14.48L20 20M8.12 8.12L12 12"></path>          </svg>        </div>        <div class="flex-grow pl-6">          <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">            Восстановление системных файлов          </h2>          <p class="text-lg leading-relaxed">            В случае некорректной работы системы и устройств, проведём анализ системных файлов и восстановим их, если они повреждены.          </p>        </div>      </div>      <div        class="flex flex-col items-center p-4 mb-6 lg:w-1/3 md:mb-0 sm:flex-row sm:items-stretch"      >        <div          class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"        >          <svg            class="w-6 h-6"            fill="none"            stroke="currentColor"            stroke-linecap="round"            stroke-linejoin="round"            stroke-width="2"            viewBox="0 0 24 24"          >            <path d="M20 21v-2a4 4 0 00-4-4H8a4 4 0 00-4 4v2"></path>            <circle cx="12" cy="7" r="4"></circle>          </svg>        </div>        <div class="flex-grow pl-6">          <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">            Установка и обновление драйверов устройств          </h2>          <p class="text-lg leading-relaxed">            При неработоспособности какого-либо из устройств или проблемах, связанных с их некорректной работой, произведём установку, обновление или откат драйверов.          </p>        </div>      </div>    </div>  </div></section>

Воу! Не так уж и просто, как хотелось бы. Безусловно, TailwindCSS, который здесь используется, тоже даёт о себе знать. Если бы мне пришлось разбираться в этом коде, я бы первым дизлайкнул статью, заявляющую, что TailwindCSS это новый шаг эволюции. Но нет, я её написал. А всё потому, что этот код можно красиво поделить на компоненты, где эта гора классов превратится в осмысленную картину, которая не только ухудшит, а даже улучшить наш developer-experience.

Но вернемся к плагину. Начнем с небольшой теории. Чтобы с помощью gulp-file-include вставить один HTML в другой, нам нужно написать команду @@include(<путь до файла>, <объект с переменными>).

При этом в gulpfile можно многое настроить под себя. У меня настроено примерно так:

function html() {  return src('src/*.html')    .pipe(fileinclude({ basepath: './src/partials' }))    .pipe(dest('dist'));}

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

• prefix можно изменить префикс с @@ на любой другой.
• suffix можно добавить суффикс.
• basepath можно настроить, как просчитываются пути в директивах. По умолчанию '@file' от HTML-файла. Есть еще '@root' от корня, или любой другой путь. В нашем случае, я создал специальную папку в src partials, где и будут лежать все наши компоненты. Важно правильно настроить Gulp, чтобы эти компоненты не попали в окончальную сборку. В примере выше, Gulp берет только файлы из корня src, не заглядывая в папки. Это то, что нам нужно.
• filters позволяет задавать функции, которые потом можно будет запускать из разметки. Смотрите примеры в документации.
• context "глобальные" переменные для условий @@if.

Также есть ряд директив:

• @@include вставка HTML-файла в другой HTML.
• @@if условия; переменные берутся из "глобального" context и/или из объекта переменных использованного @@include.
• @@for обычный цикл по массиву из context/переменных @@include.
• @@loop проходимся по массиву объектов, используя данные из них как переменные, и вставляем для каждого компонент. Может использовать JSON.

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

В нашем случае нас больше всего интересует @@loop. Мы перенесем все данные из карточек в JSON-файл, создадим компонент и передадим ему его данные, как пропсы.

Что у нас входит в данные? Правильный ответ: заголовок карточки, текст и SVG. В переменные мы можем передавать как просто текст, так и HTML как строку. Он просто подставит её, куда мы скажем.

Вот как выглядит JSON (data.json).

[  {    "title": "Оптимизация скорости",    "text": "Увеличим быстродействие системы при загрузке, уменьшим нагрузку на процессор и оперативную память, исключим из автозагрузки требовательные к ресурсам устройства программы.",    "svg": "<path d=\"M22 12h-4l-3 9L9 3l-3 9H2\"></path>"  },  {    "title": "Восстановление системных файлов",    "text": "В случае некорректной работы системы и устройств, проведём анализ системных файлов и восстановим их, если они повреждены.",    "svg": "<circle cx=\"6\" cy=\"6\" r=\"3\"></circle><circle cx=\"6\" cy=\"18\" r=\"3\"></circle><path d=\"M20 4L8.12 15.88M14.47 14.48L20 20M8.12 8.12L12 12\"></path>"  },  {    "title": "Установка и обновление драйверов устройств",    "text": "При неработоспособности какого-либо из устройств или проблемах, связанных с их некорректной работой, произведём установку, обновление или откат драйверов.",    "svg": "<path d=\"M20 21v-2a4 4 0 00-4-4H8a4 4 0 00-4 4v2\"></path><circle cx=\"12\" cy=\"7\" r=\"4\"></circle>"  }]

Теперь создадим компонент одной карточки (card.html). Переменные вставляем как @@<имя переменной>.

<div  class="flex flex-col items-center p-4 mb-6 sm:flex-row lg:w-1/3 md:mb-10 sm:items-stretch">  <div    class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"  >    <svg      class="w-6 h-6"      fill="none"      stroke="currentColor"      stroke-linecap="round"      stroke-linejoin="round"      stroke-width="2"      viewBox="0 0 24 24"    >      @@svg    </svg>  </div>  <div class="flex-grow pl-6">    <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">@@title</h2>    <p class="text-lg leading-relaxed">@@text</p>  </div></div>

Осталось только создать файл секции (index.html).

<section class="text-gray-700 body-font">  <div class="container px-5 py-24 mx-auto">    <h1 class="mb-20 text-2xl font-medium text-center text-gray-900 sm:text-3xl title-font">      Проблемы, которые я решаю    </h1>    <div class="flex flex-wrap -mx-4 -mt-4 -mb-10 sm:-m-4">      @@loop('problems/card.html', 'partials/problems/data.json')    </div>  </div></section>

Первым параметром в @@loop передаем путь до компонента (от настроенного ранее basepath), вторым путь до JSON-файла (от src).

Структура файлов выглядит вот так:

src   index.html   main.csspartials      problems          index.html          card.html          data.json...

Теперь сам index.html я могу вставить с помощью @@include в файл основной страницы.

<!DOCTYPE html><html lang="ru">  <head>    ...  </head>  <body>    ...    @@include('problems/index.html')    ...  </body></html>

Минимальными усилиями мы получили полноценное компонентное деление. При этом, это никак не отразится на результате, будет такой же HTML, как и раньше. Конечно, не могу не заметить, что это подкрепляет также тезис про TailwindCSS, он уже не кажется таким неудобным, как прежде, не так ли? Дальше дело за малым повторить всё выше перечисленное для всех секций сайта.

На этом закончим знакомство с данным плагином. Цель данной статьи было показать, как легко можно в небольших проектах избежать использование тяжеловесных современных фреймворков, и при этом сохранить те идеи, которые они с собой несут. Конечно, это не единственный вариант, как это сделать. Возможно, вы знаете другие альтернативы, интересно будет услышать о них в комментариях.

Напоследок прошу ответить на вопрос:

Очевидно, я бы не стал писать эту статью, если бы считал, что 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, пишем классы, а затем просто копируем их к себе в верстку.