Нововведения в Tailwind CSS 4.0: подробный обзор

Tailwind CSS 4.0 – это крупное обновление популярного CSS-фреймворка, которое приносит множество изменений и улучшений. В этой статье мы рассмотрим все ключевые нововведения версии 4.0, сравним их с предыдущей версией (Tailwind 3.0), приведём примеры кода и обсудим влияние на производительность и удобство разработки. Статья рассчитана на начинающих разработчиков, выходящих на новый уровень – мы постараемся объяснять всё понятным и дружелюбным языком.

Ключевые нововведения Tailwind CSS 4.0

Переход на CSS-переменные для темы

• Все значения темы как CSS-переменные. В Tailwind 4.0 все значения вашей темы (цвета, размеры, брейкпоинты и т.д.) автоматически представлены в виде CSS custom properties (CSS-переменных).
• До и после: Раньше (в Tailwind 3.x), чтобы использовать значение темы в CSS, зачастую приходилось вызывать функцию theme() или дублировать значение вручную. Теперь это не требуется – можно прямо обращаться к соответствующей CSS-переменной.
• Преимущества: Это упрощает создание динамических тем (например, можно переключать тему, меняя значения переменных в рантайме) и позволяет легко получить значение темы из JavaScript – через getComputedStyle на корневом элементе вы можете прочитать, например, значение --color-red-500.
• Пример: вместо использования в CSS чего-то вроде background-color: theme('colors.red.500') (что расширялось бы в конкретный цвет на этапе сборки), теперь можно написать background-color: var(--color-red-500). Tailwind 4.0 позаботится о том, чтобы переменная --color-red-500 была определена в вашем CSS (обычно на :root) и содержала нужное значение из палитры.

Новый подход к конфигурации: CSS-файл вместо JS

• Конфигурирование через CSS. В Tailwind 3 конфигурация (настройка цветовой темы, брейкпоинтов, плагинов и прочего) задавалась в основном через файл tailwind.config.js. В Tailwind 4 появилась возможность описывать конфигурацию прямо в CSS с помощью специальных директив.
• Импорт вместо директив @tailwind. Теперь для подключения Tailwind к проекту достаточно добавить в главный CSS-файл строку импорта:

  @import "tailwindcss";
  

  Это заменяет использование трёх директив из v3: @tailwind base;, @tailwind components; и @tailwind utilities;. Tailwind сам подтянет базовые стили, компоненты и утилиты.
• Директива @theme. Сразу после импорта можно определить тему вашего проекта прямо в CSS. Для этого служит новая директива @theme, внутри которой вы устанавливаете значения CSS-переменных, отражающих вашу тему.
• Пример конфигурации темы через CSS:

  /* Tailwind 4.0 - пример основного CSS-файла */
  @import "tailwindcss";
  
  @theme {
    --font-sans: "Inter", sans-serif;
    --color-brand: #3490dc;
    --spacing-72: 18rem;
    /* ... другие настройки темы ... */
  }
  

  В этом примере мы импортируем Tailwind и затем определяем некоторые пользовательские значения: шрифт по умолчанию, кастомный цвет brand и размер отступа 72. Tailwind подхватит эти переменные и сгенерирует классы на их основе. Таким образом можно обойтись без отдельного JS-конфига для многих случаев.
• Поддержка старого конфига. JavaScript-конфиг всё ещё поддерживается для сложных случаев, однако он не обнаруживается автоматически. Если хотите использовать существующий tailwind.config.js, нужно явно импортировать его директивой @config в вашем CSS:

  @config "./tailwind.config.js";
  

  Учтите, что некоторые опции из старого JS-конфига больше не работают (например, corePlugins, safelist и separator – о них ниже). В целом, новый CSS-подход более декларативный и простой, поэтому рекомендуется именно он.

Официальные пакеты CLI и плагин для Vite

• Модульная архитектура. Tailwind 4.0 разделил свои инструменты на отдельные пакеты для лучшей интеграции с различными сборщиками:
  • @tailwindcss/cli – пакет для использования Tailwind через CLI (командную строку).
  • @tailwindcss/postcss – плагин Tailwind для PostCSS (заменяет прямое подключение tailwindcss в PostCSS-конфиге).
  • @tailwindcss/vite – официальный плагин Tailwind CSS для сборщика Vite.
• Зачем это нужно: Такая модульность улучшает Developer Experience. Например, в Vite проекте использование специального плагина даёт более быструю сборку и обновление стилей в режиме разработки (HMR) по сравнению с использованием Tailwind через общий PostCSS-процесс.
• Автопрефиксер не нужен. Tailwind 4.0 теперь сам обрабатывает импорты CSS и добавляет вендорные префиксы для кросс-браузерности. То есть вам больше не нужны отдельные PostCSS-плагины вроде postcss-import и autoprefixer – уберите их из своей цепочки сборки. Это упрощает настройку.
• Пример изменения PostCSS-конфига: в Tailwind 3 ваш postcss.config.js мог содержать:

  // postcss.config.js (v3)
  module.exports = {
    plugins: {
     "postcss-import": {},
      "tailwindcss": {},
     "autoprefixer": {}
    }
  };
  
  // postcss.config.js (v4)
  module.exports = {
    plugins: {
     "@tailwindcss/postcss": {},
     "@tailwindcss/postcss": {}
    }
  };
  

  В новой версии мы подключаем вместо старого плагина tailwindcss пакет @tailwindcss/postcss и удаляем теперь лишние postcss-import и autoprefixer.
• CLI-команда изменилась. Если вы пользовались Tailwind CLI напрямую, обратите внимание на новое название пакета. Раньше запуск выглядел так:

  npx tailwindcss -i input.css -o output.css
  

  Теперь нужно вызывать CLI из нового пакета:

  npx @tailwindcss/cli -i input.css -o output.css
  

• Настройка Vite. В Vite-проектах теперь достаточно подключить плагин:

  // vite.config.js
  import tailwindcss from "@tailwindcss/vite";
  export default {
    plugins: [ tailwindcss() ]
  };
  

  Этот плагин заменяет собой использование PostCSS-плагина внутри Vite и обеспечивает лучшую производительность и поддержку функций Tailwind.

Изменения в утилитарных классах и значениях по умолчанию

Tailwind CSS 4.0 также изменяет ряд утилити-классов, делая их более последовательными и современными. Разработчикам, обновляющимся с предыдущих версий, важно знать об этих изменениях:

• Удалены устаревшие утилиты. Все классы, помеченные как deprecated в Tailwind 2.x/3.x, убраны:
  • Утилиты прозрачности, такие как bg-opacity-*, text-opacity-*, border-opacity-* и т.д., удалены. Вместо них уже давно используется новый синтаксис: достаточно добавить дробь к цвету. Например, вместо bg-opacity-50 теперь пишут bg-black/50 (чёрный с 50% непрозрачности).
  • Утилиты flex-grow-0/flex-grow и flex-shrink-0/flex-shrink удалены – используйте их короткие эквиваленты grow-0/grow и shrink-0/shrink (они были добавлены ещё в v3).
  • overflow-ellipsis заменён на более понятный text-ellipsis.
  • decoration-slice и decoration-clone переименованы в box-decoration-slice и box-decoration-clone соответственно для единообразия.
    Если в вашем проекте вдруг ещё встречались эти старые классы, их нужно заменить на современные аналоги. Но, скорее всего, вы уже перешли на новый синтаксис ещё в Tailwind 3.
• Переименование размеров теней, скругления и размытия. Значения некоторых утилит получили новые имена, чтобы сделать размерные шкалы более логичными:
  • То, что в v3 называлось с суффиксом *-sm, теперь называется *-xs. А то, что было "без суффикса", теперь получило суффикс -sm. По сути, добавлен новый самый маленький размер xs, а далее сдвиг: sm стал чуть больше, md и т.д. остаются как были.
  • Примеры: shadow-sm в Tailwind 4.0 стал shadow-xs. Соответственно, старый shadow (без суффикса) теперь называется shadow-sm. То же самое с размытиями: blur-sm -> blur-xs (а blur -> blur-sm), с скруглениями: rounded-sm -> rounded-xs (а просто rounded -> rounded-sm), и с тенями-фильтрами: drop-shadow-sm -> drop-shadow-xs (а drop-shadow -> drop-shadow-sm).
  • Миграция: Вам нужно пройтись по проекту и переименовать эти классы. Их не очень много, и если используете инструмент миграции, он сделает это автоматически. Однако, будьте внимательны: например, shadow теперь означает более маленькую тень, чем раньше, поэтому важно обновить на shadow-sm, чтобы получить прежний эффект.
  • Пример:

    <!-- Tailwind 3.x -->
    <div class="shadow-sm rounded-sm blur-sm ...">...</div>
    
    <!-- Tailwind 4.0 -->
    <div class="shadow-xs rounded-xs blur-xs ...">...</div>
    

    В примере видно, что мы переименовали классы, чтобы сохранить тот же уровень тени, скругления углов и размытия, что был в v3.
• Новый класс outline-hidden вместо старого outline-none.
  • Ранее класс outline-none не убирал outline (обводку фокуса) полностью, а делал его невидимым (прозрачным). Это было нужно для доступности: даже если разработчик скрывал outline, в режиме повышенной контрастности браузер всё равно показывал пунктирную рамку.
  • В Tailwind 4 решили сделать названия более очевидными:
    • outline-hidden – именно скрывает outline визуально (по сути эквивалент старого поведения outline-none в v3).
    • outline-none – теперь действительно убирает стиль обводки (outline: none), то есть вообще отключает фокусную рамку.
  • Что использовать: Если в вашем коде был focus:outline-none просто для того, чтобы убрать видимую рамку, замените его на focus:outline-hidden – так вы сохраните прежнее поведение (рамка скрыта визуально, но доступность не пострадает). Если же вы сознательно хотите полностью убрать outline даже для ассистивных технологий, можно оставить новый outline-none – но делайте это с осторожностью, чтобы не ухудшить UX для пользователей клавиатуры.
  • Пример:

    <!-- Было в Tailwind 3: скрыть обводку при фокусе -->
    <button class="focus:outline-none">Кнопка</button>
    
    <!-- Стало в Tailwind 4: эквивалентное поведение -->
    <button class="focus:outline-hidden">Кнопка</button>
    

    В примере мы заменили outline-none на outline-hidden для фокуса, чтобы сохранять прежний эффект.
• Изменение поведения класса ring.
  • Класс ring задаёт внешнее кольцо (бокс-шадоу) для фокуса элементов. В Tailwind 3 по умолчанию ring означал кольцо толщиной 3px и цвета blue-500 (синий).
  • В Tailwind 4 поведение изменилось: теперь ring сам по себе эквивалентен ring-1 (то есть 1px) и по умолчанию цвет кольца – currentColor. Проще говоря, если вы добавите класс ring без указания толщины и цвета, получите тонкую обводку, окрашенную в цвет текста элемента. Такое поведение более согласовано с тем, как работают рамки (border) и outline по умолчанию в браузерах (они тоже используют currentColor).
  • Как мигрировать: Если раньше вы полагались на толстое синее кольцо по умолчанию, теперь вам нужно указать его явно. Вместо просто ring используйте два класса: ring-3 (толщина 3px) и, например, ring-blue-500 для синего цвета. Это вернёт старый вид.
  • Пример:

    <!-- Tailwind 3: по умолчанию синее кольцо 3px -->
    <button class="focus:ring">Сохранить</button>
    
    <!-- Tailwind 4: эквивалент нужно прописать явно -->
    <button class="focus:ring-3 focus:ring-blue-500">Сохранить</button>
    

    В первом случае (v3) кнопка при фокусе получала синюю обводку 3px. Во втором (v4) мы добились того же эффекта, указав толщину ring-3 и цвет ring-blue-500. Если этого не сделать, focus:ring в v4 даст лишь 1px обводку текущего цвета текста.
  • Дополнительно: В Tailwind 4 изменён не только размер, но и дефолтный цвет ring – как сказано, на currentColor. Это значит, что кольцо фокуса будет автоматически наследовать, к примеру, ваш цвет текста или иконки. Во многих случаях это удобнее, но если нужно акцентировать фокус особым цветом – указывайте цвет явно.
• Класс container без встроенной центровки и отступов.
  • Utility-класс container (контейнер фиксированной ширины для центровки контента) в Tailwind 3 имел специальные настройки в конфигурации: можно было включить автоматическое центрирование (center: true) и задать дефолтные внутренние отступы (padding). В Tailwind 4 эти опции убраны.
  • Теперь container – это «обычный» утилитарный класс, который только задаёт максимальную ширину контента на каждом брейкпоинте (в зависимости от вашего дизайна). Он не центрирует автоматически и не добавляет паддинги.
  • Как настроить контейнер под себя: Вы можете сами расширить стиль container, используя директиву @utility или обычный CSS. Например, чтобы центрировать контейнер и добавить боковые отступы, можно написать:

    @utility container {
      margin-inline: auto;   /* центрирование по горизонтали (left/right) */
      padding-inline: 2rem;  /* внутренние отступы слева/справа */
    }
    

    Это эквивалент тому, что раньше делалось настройками center: true и padding: '2rem' в конфиге. Теперь мы явно добавили эти свойства к классу container через CSS.
  • Если вам не нужны центрирование или отступы по умолчанию, можете оставить container как есть – он просто будет выравниваться по левому краю (или куда поставите) и занимать 100% ширины до тех пор, пока не достигнет максимума на соответствующем брейкпоинте.
• Обновления Preflight (базовые стили). Tailwind включает «Preflight» – набор базовых стилей-ресетов. В 4.0 туда тоже внесены изменения:
  • Placeholder цвет: Цвет текста placeholder (атрибут placeholder у input/textarea) теперь по умолчанию берётся как текущий цвет текста с прозрачностью 50%. В Tailwind 3 по умолчанию placeholder имел фиксированный серый цвет (gray-400). Новое поведение делает placeholder более естественным – например, если у вас тёмный текст на светлом фоне, placeholder будет просто более бледной версией этого текста, а не стандартно серым. Если же вам нужен прежний единый цвет placeholder, вы можете явно его задать в своих стилях.
  • Курсор у кнопок: Tailwind больше не навязывает всем кнопкам cursor: pointer. В v3 Preflight устанавливал для <button> стиль курсора «рука» (палец), считая, что так лучше показать кликабельность. В v4 это убрано, и кнопки следуют поведению браузера по умолчанию – как правило, на них стрелочный курсор. Это изменение было сделано, чтобы не ломать нативные ожидания: по стандартам, курсор-рука предназначен для ссылок, а кнопки могут оставаться со стрелкой. Если вам больше нравится, когда над кнопками появляется рука, просто добавьте класс cursor-pointer или свой стиль для кнопок. В документации даже предложен рецепт: через @layer base задать button { cursor: pointer; } самостоятельно, если нужно.
  • Диалоги (<dialog>): Preflight 4.0 сбрасывает стили <dialog>, убирая дефолтные margin. Ранее браузеры по умолчанию центрируют <dialog> блок, давая ему auto margin. Теперь Tailwind обнуляет margin, чтобы этот элемент вёл себя как остальные (без внешних отступов). Поэтому, если вы используете <dialog> и рассчитывали на его автоматическое центрирование, вам надо будет добавить это вручную (dialog { margin: auto; } вернёт поведение центрирования модального окна).

Новые возможности кастомизации: директивы @utility, @custom-variant и prefix()

Tailwind 4.0 не только меняет существующие вещи, но и добавляет новые инструменты для более гибкой настройки под нужды разработчиков.

• Директива @utility для пользовательских классов.
  Если вам нужно добавить свой утилитарный класс (например, нестандартную тень или что-то специфичное для проекта), Tailwind 4 предлагает сделать это через новую директиву @utility.
  • Как было в v3: В предыдущих версиях вы могли написать свой класс внутри @layer utilities или @layer components, и Tailwind его включал в итоговый CSS, позволяя применять модификаторы (hover:, md: и т.д.). Однако это работало немного «магически», и порядок применения таких стилей был tricky (например, классы в @layer components всегда шли перед утилитами).
  • Как в v4: Теперь вы просто пишете отдельный блок @utility, и внутри него определяете класс и стили. Tailwind добавит его к своим утилитам. При этом используется новая фича CSS – cascade layers (каскадные слои), чтобы правильно упорядочить стили. Ваши кастомные утилиты будут сортироваться и позиционироваться автоматически, обычно вместе с остальными утилитами. Если ваша утилита задаёт несколько CSS-свойств сразу (например, кнопка с и фоном, и отступами, и радиусом), Tailwind постарается разместить её таким образом, чтобы более "специализированные" классы (которые задают одно свойство, например, отдельный bg-red-500 или p-4) могли её переопределить при конфликте. Это избавляет от головной боли с порядком подключения.
  • Пример:

    /* Tailwind 3: определение кастомного класса через @layer */
    @layer utilities {
      .tab-4 { tab-size: 4; }
    }
    /* Tailwind 4: то же самое через @utility */
    @utility tab-4 {
      tab-size: 4;
    }
    

    В примере мы создаём утилиту .tab-4 (управляет размером табуляции). В v3 мы писали её внутри @layer utilities, в v4 – через @utility. Для разработчика особой разницы нет, но новый подход надёжнее и официально поддержан. Все вариации (hover:tab-4, md:tab-4 и т.д.) будут работать автоматически.
• Кастомные вариации через @custom-variant.
  Tailwind имеет множество готовых вариаций (variants) – например, breakpoints (sm:, md:…), состояния (hover:, focus:, active:), dark mode (dark:) и т.д. Но что, если вам нужен свой модификатор? В Tailwind 4 это стало возможным через директиву @custom-variant.
  • Как это работает: Вы объявляете новый вариант, задавая правило, как он должен преобразовывать селектор. Например, чтобы определить вариант print: (стили только для печати), можно написать:

    @custom-variant print {@media print {\n  & {\n    $0\n  }\n}}
    

    (Фактический синтаксис может отличаться, но идея в том, что вы указываете, как оборачивается базовый селектор). После этого вы сможете использовать print:... в классах.
  • Пример для hover на мобильных: В официальной документации приведён пример использования @custom-variant для восстановления старого поведения hover: на touch-устройствах (мы обсудим изменение hover ниже). Например:

    @custom-variant hover (&:hover);
    

    Если вставить это где-то после импорта Tailwind, то ваш вариант hover: будет работать по старому принципу (без медиа-условия @media (hover: hover)). Обычно необходимость в этом невелика, но сам факт: теперь вы можете определять свои варианты, что открывает новые возможности при сложных требованиях к стилям.
  • Примечание: Синтаксис @custom-variant достаточно продвинутый и, вероятно, вам не понадобится на начальном этапе. Но знать о нём полезно – например, чтобы реализовать кастомные состояния или специфические медиавыражения под утилиты Tailwind.
• Изменение синтаксиса префикса классов.
  Tailwind позволяет задать префикс для всех генерируемых классов, чтобы избежать конфликтов с вашим собственным CSS или другими библиотеками. В Tailwind 3 для этого служила опция prefix в конфиге, например: { prefix: 'tw-' } – и тогда все классы начинались бы с tw- (например, tw-bg-red-500).
  В Tailwind 4 подход изменился: теперь префикс указывается прямо при импорте, а в HTML используется через двоеточие, как будто это отдельный namespace/вариант.
  • Настройка: В вашем CSS-файле импорт Tailwind можно сделать так:

    @import "tailwindcss" prefix(tw);
    

    Здесь мы указали префикс tw. Tailwind сгенерирует все утилиты с этим префиксом.
  • Использование: В HTML-классе перед каждым утилити-классом нужно написать tw:. Например, вместо <div class="p-4 bg-red-500"> станет <div class="tw:p-4 tw:bg-red-500">. Даже модификаторы пишутся с префиксом: tw:hover:bg-red-600.
  • Пример:

    <!-- Пример использования с префиксом tw: -->
    <div class="tw:flex tw:bg-gray-100 tw:p-4 tw:rounded-lg">
      Пример блока с утилитами Tailwind
    </div>
    

    В этом примере все классы (flex, bg-gray-100, p-4, rounded-lg) помечены префиксом tw:. Такой синтаксис делает код немного более многословным, зато вы точно знаете, какие классы идут от Tailwind.
  • Зачем это нужно: Префикс полезен, если вы подключаете Tailwind к существующему проекту, где могут быть пересечения имён классов, или если вы просто хотите избежать потенциальных конфликтов. Новый синтаксис через двоеточие вписывается в общую концепцию модификаторов Tailwind и унифицирует подход (все специальные вещи – через двоеточие, будь то sm: или кастомный префикс). CSS-переменные Tailwind при использовании префикса тоже получают префикс в названиях (например, --tw-color-red-500 вместо --color-red-500), чтобы не конфликтовать с вашими собственными переменными.
• Поддержка CSS-модулей, Vue, Svelte через @reference.
  Если вы работаете с компонентными фреймворками (Vue, Svelte, Astro и т.д.) или CSS Modules, где стили каждого компонента инкапсулированы, у вас могло возникать затруднение с использованием @apply и кастомных утилит Tailwind внутри этих компонентов. Дело в том, что такие стили компилируются отдельно, и по умолчанию не видят определений из вашего основного Tailwind CSS.
  Tailwind 4 представляет директиву @reference, которая решает эту проблему. Она позволяет «сослаться» на сгенерированный Tailwind CSS (или любой другой CSS-файл) без дублирования кода. Проще говоря, вы как бы говорите: «подтяни определения из того файла, чтобы я мог ими воспользоваться».
  • Как использовать: Внутри блока <style> вашего компонента (или в CSS-модуле) первым делом напишите, например:

    @reference "path/to/global-tailwind.css";
    

    Укажите путь до вашего основного CSS, где объявлены @theme, @utility и т.д. После этого в этом файле станут доступны все CSS-переменные темы и кастомные утилиты. Вы сможете смело использовать @apply с любыми классами Tailwind, и они будут применяться правильно.
  • Пример (Vue single-file component):

    <template>
      <h1>Hello world!</h1>
    </template>
    <style>
      @reference "../index.css"; /* подключаем основной Tailwind CSS */
      h1 {
        @apply text-2xl font-bold text-red-500;
      }
    </style>
    

    Здесь мы в стилях компонента ссылаемся на index.css (допустим, там наш Tailwind подключён и настроен) и применяем утилиты через @apply. Благодаря @reference, компилятор знает про эти утилиты и переменные, поэтому всё отработает.
  • Альтернатива – CSS-переменные. Кстати, можно обойтись и без @apply: раз уж все значения темы доступны как переменные, вы можете прямо использовать их. В том же примере вместо @apply text-red-500 можно написать color: var(--text-red-500); – результат будет тот же. Такой подход даже предпочтительнее в некоторых случаях, потому что не требует обработки @apply (что может слегка ускорить сборку).
  • Вывод: @reference – полезная новинка для тех, кто использует Tailwind в связке с компонентными фреймворками или CSS Modules. Это избавляет от дублирования кода (нет нужды генерировать Tailwind CSS для каждого компонента отдельно) и сохраняет удобство утилитарных классов в изолированных стилях.

Другие улучшения и изменения

Помимо больших нововведений, Tailwind CSS 4.0 включает ряд мелких доработок и оптимизаций:

• Оптимизирован селектор для space-x/space-y. Утилиты space-y-* и space-x-* добавляют равные отступы между дочерними элементами контейнера. В v3 они были реализованы через сложный селектор .space-y-N > :not([hidden]) ~ :not([hidden]), который применял margin ко всем элементам, у которых перед ними есть сосед (грубо говоря, ко второму и далее). В v4 это упростили до .space-y-N > :not(:last-child), который добавляет отступ всем элементам, кроме последнего.
  • Для горизонтального варианта space-x аналогично: используется :not(:last-child) с правым margin (или другим свойством, обеспечивающим промежуток).
  • Зачем это сделано: Новый селектор гораздо менее ресурсоёмкий для браузера. Старый селектор с :not([hidden]) ~ :not([hidden]) мог тормозить отрисовку, особенно если на странице тысячи элементов. Теперь воздействие минимальное.
  • Изменения в поведении: В подавляющем большинстве случаев вы не заметите разницы. Однако, если вы комбинировали space-* с другими отступами на тех же элементах или использовали их на строчных элементах, новое поведение чуть отличается (например, отступы теперь добавляются к нижнему краю каждого элемента, кроме последнего, вместо к верхнему краю каждого элемента, кроме первого, как было раньше – но визуально это эквивалентно). Если вдруг у вас появятся конфликты, разработчики Tailwind рекомендуют перейти на использование Flexbox/Grid и свойства gap, которые нативно решают задачу промежутков между элементами и зачастую более предсказуемы.
  • Иллюстрация:

    /* Было в Tailwind 3: */
    .space-y-4 > :not([hidden]) ~ :not([hidden]) { margin-top: 1rem; }
    /* Стало в Tailwind 4: */
    .space-y-4 > :not(:last-child) { margin-bottom: 1rem; }
    

    Два селектора дают одинаковый визуальный результат (вертикальный промежуток 1rem между элементами), но второй выполняется быстрее. Обратите внимание: если у последнего элемента были какие-то свои margin, теперь это не влияет на space-y (т.к. последний элемент просто исключается, и отступы ставятся предыдущим элементам).
• Улучшенная работа градиентов с вариациями. Если вы использовали градиенты и одновременно модификаторы вроде dark: или hover:, в v3 могли возникать странности. Например:

  <div class="bg-gradient-to-r from-red-500 to-yellow-400 dark:from-blue-500">
    ...
  </div>
  

  В тёмной теме (dark:) мы переопределили только начальный цвет градиента (from-), но не конечный (to-). В Tailwind 3 это приводило к тому, что конечный цвет становился прозрачным – то есть градиент на тёмной теме фактически был от синего к прозрачному. В Tailwind 4 такое поведение исправлено: если вы не переопределили to- для варианта, он останется тем же (to-yellow-400 в данном примере, даже в тёмной теме). Это более логично и предсказуемо.
  • Новый утилит via-none. В связи с этим добавлена утилита via-none, на случай если вы действительно хотите убрать средний цвет градиента при определённом модификаторе. Например, если у вас градиент из трёх цветов (from-, via-, to-), а в тёмной теме вы хотите его упростить до двух цветов, вы можете добавить dark:via-none. Тогда средний цвет станет прозрачным.
  • В общем, работа с градиентами и модификаторами стала более интуитивной: то, что вы не указали явно, не будет внезапно сброшено. Скорее, сохранится предыдущая настройка.
• Hover-стили на мобильных. Это изменение скорее логики, чем кода: в Tailwind 4 модификатор hover: генерирует CSS, который срабатывает только на устройствах, где поддерживается hover. То есть он автоматически оборачивается в медиа-условие @media (hover: hover). Практически это значит, что на тач-устройствах (телефонах, планшетах без мыши) ваши :hover стили не применятся вовсе.
  • Почему: Раньше, без этого условия, некоторые мобильные браузеры могли применять :hover стили при первом тапе или до тапа (например, Safari iOS делает тап = hover + click одновременно, что порой вызывало путаницу). Новый подход исключает hover-стили из загрузки на мобильных, что чуть-чуть оптимизирует CSS и предотвращает странные эффекты.
  • Что учесть: Если вы рассчитывали на то, что при тапе на элемент на мобильном появится hover-стиль (некоторые так делали подсказки или имитацию фокуса), то теперь этого не произойдёт. Для таких случаев придётся использовать JavaScript (например, добавлять класс при тапе) или CSS-хак через :focus вместо :hover.
  • Как вернуть старое: Если вам критично вернуть прежнее поведение, можно определить собственный вариант через @custom-variant hover (&:hover), как мы упоминали ранее, чтобы переопределить встроенный (но делать это стоит только в крайнем случае). В целом же, авторы Tailwind рекомендуют считать hover-эффекты улучшением для десктопа, но не основным способом взаимодействия – всё важное на странице должно быть доступно по клику/тачу без зависимостей от наведения курсора.
• Transition анимирует outline-color. Утилиты transition и transition-colors в Tailwind 4 включают свойство outline-color в перечень анимируемых. Раньше они охватывали только фон, цвет текста, бордеры. Зачем это нужно: если у элемента при фокусе меняется outline (например, вы добавляете outline-2 outline-blue-500 при фокусе), то с transition в v4 цвет обводки будет плавно переходить от прежнего к новому. В Tailwind 3 такой переход происходил мгновенно (outline не был в списке анимируемых).
  • Побочный эффект: В некоторых случаях вы можете заметить «лишнюю» анимацию. Например, кнопка без обводки в нормальном состоянии при фокусе получает синий outline – и вот этот синий может сначала появиться бледным и быстро стать насыщенным, т.к. браузер анимирует от прозрачного outline к синему. Если вам это не нужно, решается просто: задайте outline-color явно и в нефокусном состоянии (например, outline-transparent), тогда анимация будет от прозрачного к синему, но вы это не увидите, либо отключите transition для outline. В любом случае, это мелочь, но улучшение делает интерфейс более плавным по умолчанию.
• Удалены опции corePlugins, safelist, separator из конфигурации.
  В Tailwind 3 в конфиге можно было отключать целые группы утилит через corePlugins (например, не генерировать вовсе утилиты для таблиц или для миксов) – в JIT-режиме это было не столь актуально, но оставалось. Также была опция safelist – список классов, которые нужно гарантированно включить в итоговый CSS (на случай динамически формируемых имён, которые JIT мог не увидеть в коде). И separator – символ, используемый для разделения модификаторов (по умолчанию двоеточие, :).
  В Tailwind 4 эти настройки не поддерживаются.
  • corePlugins: теперь отключение не нужно – если вы не используете ту или иную утилиту, JIT-просмотр просто не найдёт её и не включит в CSS. Например, если в коде нигде нет классов начинающихся на table-, то финальный CSS вообще не будет содержать табличных стилей Tailwind. Поэтому управление через corePlugins стало избыточным.
  • safelist: тоже частично потерял смысл – JIT генерирует стили «на лету» по обнаруженным классам. Если классы формируются динамически (например, на основе пользовательских данных), вместо safelist обычно можно применить функцию, которая генерирует эти классы где-то в видимом для Tailwind месте, либо воспользоваться импортом готового файла стилей. В крайнем случае можно всё еще воспользоваться утилитой CLI tailwindcss для генерации всех классов и выбрать нужные. Но прямой аналог safelist не предусмотрен.
  • separator: классы-модификаторы теперь жестко используют двоеточие. Это значит, что если ваша среда (например, какие-то шаблонизаторы) не позволяла двоеточие в именах классов, придётся искать обходные пути или отказаться от таких модификаторов. Однако это очень редкий кейс. В основном, отказ от настройки separator упрощает экосистему – все знают, что разделитель всегда :, и не нужно учитывать различные варианты в инструментах.
• Прочие мелочи:
  • В JavaScript API Tailwind удалена функция resolveConfig. Раньше она могла преобразовать JS-конфиг (с вложенными объектами) в плоский объект со всеми значениями, чтобы вы могли использовать их в своем JS-коде. Теперь, когда все значения есть в виде CSS-переменных, от этого отказались. Предлагается вместо этого, если очень надо получить значение темы, считать его из сгенерированных стилей через DOM. Это уменьшает размер бандла, поскольку не тащит весь конфиг в JS.
  • Появился новый брейкпоинт 3xl в стандартной конфигурации. Он примерно равен 1920px (в доке указан как 120rem). Так что теперь из коробки доступны модификаторы 3xl: для очень больших экранов. Раньше максимальным был 2xl (~1536px).
  • Tailwind 4 требует Node.js 20 или выше. Если вы используете более старую версию Node, нужно обновиться, иначе ни CLI, ни утилита миграции не запустятся. Node 20 – свежая LTS-версия на 2023/2024 год, так что это разумное требование, но его важно учитывать.

Сравнение с предыдущими версиями (Tailwind CSS 3.x)

Чтобы лучше понять контекст, сравним Tailwind 4.0 с версией 3.0 по основным моментам:

• Подключение и конфигурация: В Tailwind 3 основным способом настройки был JS-файл конфигурации, а стили подключались через директивы @tailwind в CSS. В Tailwind 4 акцент сделан на CSS-first подходе: один импорт, и конфигурация прямо в CSS через @theme. При этом возможность старого способа сохраняется, но новое решение более интегрировано с процессом построения стилей.
• Just-in-Time компиляция: Tailwind 3 перешёл на JIT-компиляцию по умолчанию – когда стили генерируются в момент использования классов. Tailwind 4 продолжает эту практику, так что производительность генерации стилей остаётся высокой. Разработчик, как и в v3, просто пишет утилити-классы, и нужный CSS появляется, без необходимости вручную пересобирать всё.
• Утилитарные классы: Tailwind 4 привнёс небольшие правки в систему классов (переименовал некоторые, удалил legacy-варианты, поменял дефолтные значения, как мы подробно разобрали). Tailwind 3, в сравнении, имел немного другие имена (shadow-sm vs shadow-xs и т.д.) и некоторые классы, которые теперь исчезли. Но концептуально принцип утилитарных классов остался тем же – у вас по-прежнему есть сотни маленьких классов для всех свойств CSS, просто обновилась их «гармония» и подчищены старые хвосты.
• Новые возможности: Tailwind 3 был крупным обновлением с JIT, но Tailwind 4 идёт ещё дальше в инновациях: использование CSS-переменных для темы, поддержка CSS cascade layers (@utility), пользовательских модификаторов (@custom-variant), улучшенная интеграция с фреймворками (@reference). Этого всего в 3.0 ещё не было. Эти возможности делают Tailwind более гибким и готовым к будущим обновлениям CSS.
• Производительность: Tailwind 3 уже отличался хорошей производительностью и малым итоговым размером CSS (за счёт удаления неиспользуемых классов). Tailwind 4 ещё более оптимизирован: новый селектор для space-* снижает нагрузку на браузер, CSS-переменные позволяют избежать повторения одинаковых значений в каждой утилите (CSS становится чуть компактнее), а отказ от посторонних плагинов (Autoprefixer) упрощает и немного ускоряет сборку. Для разработчика приятным бонусом будет плагин Vite, который ускоряет обновление стилей при разработке.
• Совместимость и экосистема: Tailwind 4 требует более новой среды (Node 20) и бросает поддержку устаревших вещей (IE11 был отрезан ещё в v3, а v4 исключил даже упоминания о нём). То есть 4.0 ориентирован на современные браузеры и инструменты. Это означает, что при переходе на него разработчики должны быть готовы использовать актуальные версии сборщиков, Node.js и т.д. Сообщество Tailwind, впрочем, активно мигрирует – уже появляются плагины, обновлённые под 4.0, и опыт других разработчиков, делящихся переходом, что облегчает обновление.

В целом, Tailwind CSS 4.0 продолжает курс, заданный в 3.0, но делает фреймворк ещё более удобным, современным и нацеленным на масштабируемость. Если Tailwind 3 был большой эволюцией с введением JIT, то Tailwind 4 шлифует опыт разработчика и вводит поддержу новейших возможностей CSS прямо «из коробки».

Примеры кода, демонстрирующие изменения

(Ниже приведены несколько примеров, иллюстрирующих новые возможности и изменения Tailwind CSS 4.0 на практике.)

• Импорт стилей вместо директив @tailwind:

  /* Tailwind 3: подключение через директивы */
  @tailwind base;
  @tailwind components;
  @tailwind utilities;
  
  /* Tailwind 4: подключение через импорт */
  @import "tailwindcss";
  

  Комментарий: В новой версии достаточно одной строки импорта – Tailwind сам включит базовые стили, компоненты и утилиты. Это упрощает setup и избавляет от трёх отдельных директив.

• Новый синтаксис префикса классов:

  /* В файле CSS: задаём префикс tw для всех классов Tailwind */
  @import "tailwindcss" prefix(tw);
  

  <!-- В HTML: используем утилиты с префиксом tw: -->
  <div class="tw:p-4 tw:bg-gray-100 tw:rounded-lg">
    Содержимое
  </div>
  

  Комментарий: Мы указали префикс tw. Теперь в HTML перед каждым классом Tailwind ставим tw:. Например, p-4 превратился в tw:p-4. Это помогает избежать конфликтов имён и ясно отделяет стили фреймворка.

• Переход от старых утилит к новым:

  <!-- Tailwind 3.x: старые названия классов -->
  <input class="focus:outline-none shadow-sm rounded-sm" type="text" placeholder="..." />
  
  <!-- Tailwind 4.0: новые названия классов -->
  <input class="focus:outline-hidden shadow-xs rounded-xs" type="text" placeholder="..." />
  

  Комментарий: Во втором варианте мы заменили устаревшие классы на актуальные. outline-none стал outline-hidden (чтобы лишь скрыть outline, а не убрать его полностью), shadow-sm и rounded-sm переименованы в более мелкие shadow-xs и rounded-xs соответственно. В результате элемент будет стилизован так же, как в прежней версии.

• Использование CSS-переменных темы напрямую:

  /* Предположим, в @theme задано: --color-brand: #3490dc; */
  .header {
    /* Tailwind 3: пришлось бы использовать theme() или продублировать значение */
    /* Tailwind 4: можно использовать CSS-переменную напрямую */
    color: var(--color-brand);
  }
  

  Комментарий: Здесь .header получает цвет текста из переменной --color-brand, которую мы определили как часть темы. В Tailwind 3 для этого пришлось бы либо прописать значение цвета явно, либо использовать функцию theme() внутри CSS (что не везде возможно). Теперь всё проще – --color-brand доступна как переменная во всём проекте.

• Пример кастомной утилиты и варианта:

  /* Определяем новую утилиту .deep-shadow через @utility */
  @utility deep-shadow {
    box-shadow: 0 0 10px rgba(0,0,0,0.5);
  }
  /* Определяем пользовательский вариант "active:" через @custom-variant */
  @custom-variant active (&:active);
  

  <!-- Используем кастомную утилиту с пользовательским вариантом: -->
  <button class="deep-shadow active:deep-shadow">Нажми меня</button>
  

  Комментарий: В CSS мы добавили свою утилиту .deep-shadow (даёт элементу сильную тень) и определили вариант active: так, чтобы он срабатывал при нажатии (:active). В HTML мы применяем тень к кнопке и дублируем её с модификатором active:. В результате у кнопки при клике будет такая же тень, как в покое (для примера). Этот кейс демонстрирует кастомизацию: таких инструментов в v3 не было, а в v4 мы легко расширяем фреймворк под свои нужды.

(Приведённые примеры отражают некоторые распространённые ситуации, с которыми вы можете столкнуться при переходе на Tailwind 4.0.)

Влияние обновлений на производительность и удобство разработки

Обновление до Tailwind CSS 4.0 позитивно сказалось и на производительности приложений, и на удобстве работы для разработчиков:

• Более лёгкий CSS и быстрее рендеринг. За счёт перехода на CSS-переменные итоговый сгенерированный CSS может стать компактнее. Вместо того чтобы повторять одинаковые значения в десятках классов, Tailwind объявляет их один раз (как переменные) и потом использует. Кроме того, удаление устаревших утилит и упрощение селекторов (например, для space-*) снижает нагрузку на браузер при расчёте стилей. Страница будет отображаться чуть быстрее, особенно если на ней много элементов, к которым применены утилити-классы.
• Оптимизация больших страниц. Если у вас страницы с очень большим числом элементов (таблицы, списки и т.д.), изменение реализации space-x/space-y убирает потенциальные тормоза. Старый селектор мог влиять на производительность, новый практически нет – значит, вы можете смелее использовать утилиты расстояний, не опасаясь, что на длинном списке что-то просядет.
• Проще настройка и интеграция. Tailwind 4.0 убирает несколько шагов из начальной настройки проекта. Теперь, чтобы стартовать, достаточно установить пакет Tailwind и подключить его – не нужно отдельно тянуть autoprefixer или настраивать PostCSS Import. Меньше настроек – меньше шансов запутаться у начинающего разработчика. А готовые решения для популярных инструментов (CLI, Vite) позволяют сразу приступить к работе без длительных танцев с бубном.
• Современные возможности CSS – из коробки. Переход на CSS-переменные означает, что вы можете легко делать темы, темную/светлую схему, настроения цветов в рантайме без дополнительных библиотек. Cascade layers (@utility) дают более предсказуемый порядок применения стилей, что оценят разработчики крупных проектов, где важно правильно переопределять стили. Все новые возможности CSS (современные цветовые пространства, медиа-запросы по возможности hover и т.д.) Tailwind 4 поддерживает сразу, вам не нужно изобретать свои решения.
• Меньше зависимость от JavaScript. Это, на первый взгляд, странное заявление, ведь Tailwind – CSS-фреймворк. Но ранее, если вы хотели, например, анимировать что-то до определённого цвета или вычислить в JS, какой отступ использовать из темы, вам приходилось либо дублировать эту информацию в JS, либо тянуть конфиг. Теперь вы можете просто считать CSS-переменную из сгенерированных стилей (анимационные библиотеки типа Framer Motion умеют работать с CSS-переменными напрямую). Это уменьшает дублирование логики между CSS и JS и может снизить объем JS-кода, что полезно для производительности приложения.
• Улучшения “по умолчанию” для UX. Некоторые изменения, хоть и мелкие, улучшают пользовательский опыт: placeholder текст стал более гармоничным (полупрозрачный, а не серый), outline при фокусе теперь переходит плавно к новому цвету, градиенты ведут себя консистентно в тёмной теме. Всё это мелочи, которые делают интерфейс более аккуратным без дополнительных усилий.
• Удобство разработки в современных фреймворках. Появление @reference значительно облегчает работу с Tailwind в связке с Vue, Svelte, React (CSS Modules) и т.д. Раньше приходилось либо дублировать стили, либо выносить больше логики в глобальные файлы, теперь же можно пользоваться утилитами локально, сохраняя изоляцию стилей. Это ускоряет разработку компонентов и позволяет новичкам применять Tailwind даже в сложных архитектурах, не сталкиваясь с загадочными проблемами видимости стилей.
• Инструменты миграции и документация. Хотя это относится не прямо к фреймворку, а к сопутствующему опыту: Tailwind Labs предоставили отличный Upgrade Guide и CLI-утилиту для обновления. Это значит, что переход на 4.0 максимально автоматизирован – а значит, меньше шансов допустить ошибку и сломать что-то при обновлении. Для начинающего (и не только) разработчика это огромный плюс в удобстве.

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

Советы по миграции на Tailwind CSS 4.0

Если вы уже использовали Tailwind 3.x и решили перейти на 4.0, вот несколько рекомендаций, чтобы процесс прошёл гладко:

1. Воспользуйтесь официальным инструментом миграции. Разработчики Tailwind подготовили утилиту, которая автоматизирует большую часть перехода. Запустите в терминале команду:

   npx @tailwindcss/upgrade
   

   Этот скрипт обновит версию Tailwind в вашем проекте до 4.0, а затем попытается автоматически внести изменения в файлы: обновит tailwind.config.js (возможно, преобразует его в CSS с @theme), подправит postcss.config.js (удалит autoprefixer/import), найдёт и переименует устаревшие утилити-классы в вашем коде (например, заменит shadow-sm на shadow-xs).
   • Важно: Утилита требует Node.js версии 20 или выше. Проверьте версию Node перед запуском (node -v). Если версия ниже – обновитесь, иначе миграция не стартует.
   • Совет: Выполняйте миграцию в новой ветке репозитория или скопируйте проект для теста. Так вы сможете спокойно просмотреть все изменения (с помощью git diff) и убедиться, что всё работает, прежде чем сливать изменения в основную ветку.
2. Обновите подключение Tailwind в стилях. После обновления пакета проверьте ваши CSS-файлы. Если раньше вы использовали @tailwind base; @tailwind components; @tailwind utilities;, замените эти строки на:

   @import "tailwindcss";
   

   Больше ничего делать не нужно – одна строка импортирует все слои. Если у вас было несколько точек входа (например, отдельные файлы для темной темы и т.д.), убедитесь, что везде заменили.
   • Если проект использует PostCSS, в его конфигурации (postcss.config.js) уберите плагины autoprefixer и postcss-import (если были). Вместо плагина tailwindcss подключите @tailwindcss/postcss. Это уже должно сделать @tailwindcss/upgrade, но перепроверьте.
   • Если вы использовали Tailwind CLI, обновите команды npm-скриптов на новое имя. Например, вместо tailwindcss -i ./src/input.css -o ./dist/output.css напишите @tailwindcss/cli -i ./src/input.css -o ./dist/output.css. Путь к файлам указывать так же, изменилось только название команды.
3. Проверьте конфигурацию (tailwind.config). Инструмент миграции может преобразовать ваш tailwind.config.js в CSS (обычно он создаёт файл, например, tailwind.config.css с директивой @theme и т.д.). Если у вас небольшой конфиг, удобно перейти на CSS-формат – правьте тему прямо в нём. Но если конфиг был сложным (с JavaScript-логикой), вы можете оставить его как есть. Только помните, что теперь Tailwind не прочитает его сам. Нужно явно импортировать конфиг директивой @config в ваш основной CSS, как показано выше.
   • Убедитесь, что выкинули из конфига опции corePlugins, safelist и separator – они не работают в v4. Если вам критически нужно было что-то из этого, ищите альтернативы (например, safelist можно заменить созданием фрагмента HTML со всеми нужными классами, чтобы Tailwind их увидел).
   • Проверьте секцию theme. В CSS-конфиге (директива @theme) синтаксис немного другой: ключи становятся именами CSS-переменных. Инструмент должен был правильно их перенести. Например, screens: { xl: "1280px" } превратится в --breakpoint-xl: 80rem; внутри @theme. Обычно здесь всё проходит гладко, но на всякий случай, протестируйте брейкпоинты, цвета и т.д. после миграции.
4. Обойдите код и замените устаревшие классы. Хотя скрипт миграции делает замену по шаблону, лучше самостоятельно просмотреть критические места:
   • Классы прозрачности: убедитесь, что нигде не осталось bg-opacity-*, text-opacity-* и прочих. Теперь должно использоваться bg-color/opacity. Если мигратор что-то пропустил (маловероятно), замените вручную.
   • Тени, скругления, размытость: найдите в проекте все вхождения shadow-, rounded-, blur-, drop-shadow-, backdrop-blur- без указания размера или с -sm. Их нужно маппить на новые названия (-xs и т.д.). Например, глобальный поиск по проекту class="[^"]*shadow[^"-] (регэксп для поиска shadow не в составе большего слова) может помочь выявить такие места. Но если использовали upgrade-скрипт, он, вероятно, уже сделал это.
   • Outline и ring: особое внимание уделите состояниям фокуса. Если у вас есть focus:outline-none, решите, что вы хотите: заменить на focus:outline-hidden (скорее всего, да), либо оставить focus:outline-none (теперь уберёт outline полностью – будьте осторожны). Поищите просто outline-none по проекту.
     Также найдите class="[^"]*ring($|[ :"]) – т.е. слово ring как отдельный класс. Такие случаи замените на ring-3 ring-color, где вместо color подставьте нужный цвет. Чаще всего это ring-blue-500, если вы ничего не меняли (потому что старый ring был синего цвета). Но возможно, у вас где-то был ring-red-500 рядом – тогда добавить ring-3 достаточно. В общем, везде, где раньше писали просто ring, теперь нужно уточнить толщину.
   • Container: Проверьте использование класса container. Если вы полагались на его центрирование, теперь элементы могут «прижаться» к левому краю. Решение – добавить родителю класс mx-auto (для центрирования) и, если нужно, px-4 (для боковых отступов) или воспользоваться @utility container, как описано выше. В любом случае, проверьте страницы с контейнерами.
   • Hover на touch: Откройте ваш проект на мобильном устройстве или в эмуляторе touch-экрана. Убедитесь, что ничего критичного не пропало из-за нового поведения hover:. Например, выпадающие меню, которые открывались по :hover, теперь не будут работать на мобильном вообще. Нужно сделать так, чтобы они открывались по тапу (например, по клику на кнопку или по :focus). Возможно, потребуется небольшое исправление.
5. Обновление стилей в компонентах (Vue, React и т.д.). Если у вас проект на фреймворке:
   • Если вы используете CSS Modules или стили внутри компонентов, добавьте директиву @reference в те файлы, где вы используете @apply или рассчитываете на переменные Tailwind. Без этого в v4 они не увидят обновлённые значения темы. Раньше это работало «автоматически», потому что Tailwind глобально прокидывал некоторые вещи, но теперь – нет.
   • Рассмотрите отказ от @apply в пользу CSS-переменных. Меньше нагрузка на сборщик и более явные стили. Например, вместо @apply bg-red-500 можно написать background-color: var(--color-red-500). Tailwind 4 делает такой подход особенно простым.
6. Полное тестирование. После обновления тщательно проверьте интерфейс: пройдитесь по всем основным страницам, компонентам. Обратите внимание на мелочи: где-то цвета бордеров могли слегка измениться (из-за перехода border по умолчанию на currentColor, например, если вы ставили просто border без указания цвета), где-то placeholder стал другого оттенка, где-то, как упоминалось, кнопка курсор не меняет. В идеале, все эти вещи либо незначительны, либо легко исправимы, но лучше выявить их сразу.
7. Обратитесь к документации и сообществу при необходимости. Документация Tailwind CSS очень подробная: раздел Upgrade Guide на сайте описывает все изменения (мы многие из них здесь перечислили). Если что-то непонятно, посмотрите примеры там. Также, сообщество (форумы, чаты) наверняка обсуждает переход – можно найти ответы на распространённые вопросы. Помните, что вы не одиноки в миграции – тысячи проектов делают то же самое, и опыт сообщества поможет найти решения для любых нестандартных ситуаций.

Следуя этим рекомендациям, вы плавно переведёте свой проект на Tailwind CSS 4.0. Миграция может показаться сложной, но на практике, благодаря автоматическому инструменту и ясному гайду, всё сводится к относительно несложным правкам. Зато затем вы сможете пользоваться всеми преимуществами новой версии.

Возможные минусы и спорные изменения

Любое крупное обновление – это компромисс между новыми фичами и отказом от старых решений. Рассмотрим, какие изменения в Tailwind 4.0 могут вызвать вопросы или неудобства у разработчиков:

• Трудозатраты на обновление кода. Основной минус – необходимость пройтись по коду и внести изменения. В больших проектах переименование классов (shadow-sm → shadow-xs и т.д.) и проверка всех мест может занять время. Инструмент миграции автоматизирует многое, но разработчику всё равно нужно понимать, что поменялось, и убедиться, что ничего не сломалось. Для совсем начинающего разработчика это может быть стрессом.
• Новый формат конфигурации. Переезд на декларативную конфигурацию в CSS понравится не всем. Те, кто ценил гибкость JS-конфига (условия, вычисления, использование сторонних данных), могут почувствовать себя ограниченными. Да, JS-конфиг оставили, но подключение его чуть более хлопотное, и некоторые возможности (типа corePlugins) убрали. Некоторым придётся изменить привычный workflow. Впрочем, можно смотреть на это и как на плюс – конфиг теперь чище и короче, а сложные вещи в нём изначально не приветствуются.
• Удаление safelist. Проекты, генерирующие классы динамически (например, на основе данных с бэкенда), раньше могли использовать safelist, чтобы включить нужные классы заранее. Теперь придётся искать обходные пути, например, генерировать эти классы и вставлять где-то в код (что не всегда удобно или возможно). Это изменение может вызвать дискуссии, но логика разработчиков Tailwind в том, что safelist был скорее костылём, и лучше спроектировать код так, чтобы явно использовать необходимые утилиты.
• Hover-наведения на мобильных. Решение отключить :hover стили на тач-устройствах – спорное. С одной стороны, это следует спецификации (смысл наведения на устройствах без курсора отсутствует), с другой – ряд разработчиков пользовались тем, что мобильные браузеры применяли :hover нажатому элементу. Например, могла быть подсветка элементов списка при тапе без JS. Теперь такого не будет. Некоторые могут считать это ухудшением UX на мобильных, а кто-то, наоборот, улучшением за счёт удаления лишних стилей. В любом случае, тем, кто полагался на старое поведение, придётся адаптироваться.
• Изменение дефолтов стилий. Пара «безобидных» изменений – placeholder и курсор кнопки – тоже вызвали разные реакции. Кому-то нравилось, что Tailwind заботится о том, чтобы кнопки всегда показывали cursor: pointer; теперь нужно помнить делать это самому. Другие рады, что убрали вмешательство во встроенные стили. То же с placeholder: большинству обновление цвета даже незаметно или выглядит лучше, но, возможно, в чьём-то дизайне упор делался именно на определённый оттенок серого placeholder, теперь он изменился. Такие вещи легко правятся, но требуют внимания.
• Потребность в актуальной инфраструктуре. Требование Node.js 20 и ориентация на современные браузеры могут стать барьером для проектов, застрявших на старых версиях инструментов. Если у кого-то сложная среда развертывания, где нельзя быстро обновить Node, или используются плагины, не совместимые с Tailwind 4, придётся либо замедлить обновление, либо искать временные решения. Впрочем, поддержка Tailwind 3 какое-то время будет продолжаться (вы всегда можете оставаться на старой версии, если новая вам недоступна).
• Новая терминология и фичи. Начинающим разработчикам придётся выучить новые концепции: что такое @theme, @utility, как теперь задавать prefix, почему некоторые вещи убрали. Кривая обучения слегка увеличилась. Однако документация хорошо объясняет эти моменты, и в этой статье мы тоже их разобрали. Со временем всё это станет привычным.
• Возможные баги свежей версии. Несмотря на тестирование, в первых релизах 4.0 могут быть ошибки или упущенные сценарии. Сообщество наверняка быстро найдет и сообщит о них, и выйдут патчи. Но те, кто переходит сразу, могут столкнуться с парой неожиданных багов. Обычно это быстро решается обновлением до 4.0.x, но стоит упомянуть: раннее принятие новой версии иногда чревато такими мелочами.

Важно понимать, что большая часть перечисленных «минусов» – временные неудобства или специфичные случаи. Tailwind CSS 4.0 стремится улучшить фреймворк в долгосрочной перспективе, поэтому изменения и отказ от старого неизбежны. Команда Tailwind известна тем, что внимательно относится к отклику сообщества: спорные моменты обсуждаются и при необходимости смягчаются (например, если какой-то use-case сильно страдает, могут предложить альтернативное решение или вернуть поддержку). На момент выхода 4.0 уже проведена большая работа, чтобы большинство проектов могло обновиться с минимумом боли.

Заключение: Tailwind CSS 4.0 – это шаг вперёд к более современному, чистому и гибкому фреймворку утилитарных классов. Он упрощает конфигурацию, лучше использует возможности CSS, ускоряет работу и даёт разработчикам новые инструменты для тонкой настройки. Начинающим разработчикам, которые хотят расти, изучение Tailwind 4.0 даст ценное понимание того, куда движется фронтенд-разработка: использование CSS-переменных, каскадных слоёв, модульность. Первое знакомство с обновлением может потребовать времени, но результат того стоит. Надеемся, этот обзор помог вам разобраться в нововведениях и подготовиться к переходу. Удачи в миграции и приятной разработки с Tailwind CSS 4.0!