Справжня причина, чому всі сперечаються про Tailwind CSS v4

Дебати навколо Tailwind CSS v4 тривають усюди. Більшість людей сперечаються не про те.

Справжнє питання не в протистоянні утилітарних класів та інлайнових стилів. Воно в тому, де зберігаються ваші стилі та хто несе когнітивне навантаження.

Tailwind v4 переносить конфігурацію безпосередньо у ваш CSS-файл. Ви використовуєте @theme замість JavaScript-файлу конфігурації. Це робить робочі процеси чистішими.

Але це не причина драми. Драма полягає в тому, як v4 полегшує використання двох різних підходів.

Паттерн 1: Утилітарні класи у ваших компонентах. Ви пишете класи безпосередньо в HTML або JSX. Це чітко вказує на те, як виглядає елемент.

Паттерн 2: Підхід @apply. Ви створюєте семантичні класи, такі як .alert або .alert--error, у CSS-файлі. Це вказує на те, чим є елемент.

Обидва способи працюють. Жоден із них не є помилковим. Вони базуються на різних філософіях.

Група А вірить у колокацію. Все залишається в одному місці. Група Б вірить у семантичні назви. Їм потрібні імена, що описують призначення.

Коли дизайнер змінює колір помилки з червоного на помаранчевий, Група А шукає зміни у файлах коду. Група Б змінює один рядок у CSS-файлі.

Tailwind v4 робить @apply більш природним. Це посилює напруженість.

Ось як обрати залежно від розміру вашої команди:

  • Невеликі команди: Використовуйте утилітарні класи. Вам не потрібно витрачати час на назви класів. Ви працюєте швидше, коли всі працюють з одними й тими ж файлами.

  • Бібліотеки компонентів: Використовуйте @apply або CSS-змінні. Вашим користувачам не потрібно знати ваші внутрішні дизайн-токени.

  • Великі компанії: Використовуйте гібридну модель. Дозвольте команді дизайн-системи відповідати за семантичні класи. Дозвольте розробникам застосунків використовувати утиліти для швидкої верстки.

Не використовуйте @apply лише для того, щоб уникнути читання довгих рядків класів. Це не стратегія. Це ухилення.

Найгучніші критики часто борються зі своїми інструментами, а не з фреймворком. Якщо вашому редактору бракує IntelliSense або у вашій команді немає системи дизайн-токенів, робочий процес здаватиметься зламаним.

Виправте свій робочий процес, перш ніж звинувачувати фреймворк.

Tailwind v4 — це потужний реліз. Конфігурація підходом CSS-first краща. Дебати — це лише ознака того, що командам потрібно приймати чіткі рішення.

Зробіть вибір. Задокументуйте його. Рухайтеся далі.

Який підхід у вашій команді? Ви використовуєте утилітарні класи чи @apply?

Джерело: https://dev.to/enjoy_kumawat/the-real-reason-everyones-fighting-about-tailwind-css-v4-4o0g