Відходження від CSS-in-JS під час виконання: серверні компоненти та стилі під час збірки
Чому використання CSS у JS під час виконання конфліктує з React Server Components та цілями щодо продуктивності, як порівнюються Tailwind, CSS Modules та бібліотеки без використання під час виконання, та як безпечно здійснити міграцію.
Джерела: Why CSS-in-JS Is Dying in 2026: Performance, Server Components, and What to Use Instead
Протягом кількох років бібліотеки CSS-in-JS у часі виконання, такі як styled-components та Emotion, були основним способом стилізації компонентів React: стилі, прив’язані до конкретного компонента, значення, які залежать від параметрів, та відсутність конфліктів імен глобальних класів. З того часу екосистема почала переорієнтовуватися на стилі, які генеруються під час збирання проекту, переважно через вимоги до продуктивності та появу React Server Components. У цій статті пояснюється, що змінилося, порівнюються основні альтернативи, та наводиться практичне критерій для вирішення, коли варто мігрувати існуючу базу коду, а коли краще залишити все як є.
Багато команд, як великих, так і малих, вже перейшли на стилізацію поза межами часу виконання, і ці причини мають значення перед тим, як обрати певний підхід.
Витрати на генерацію стилів у браузері
Бібліотеки CSS-in-JS, які працюють під час виконання, генерують CSS під час роботи вашого додатку. Коли компоненти відображаються, бібліотека перетворює визначення стилів (включаючи всі значення, які залежать від параметрів) на правила CSS, створює імена класів та вставляє теги <style> у документ. Ці операції виконуються на основному потоці пристрою користувача. Опубліковані тестування, які порівнюють їх із статичним CSS, показують уповільнення процесу відображення на рівні від 20 до 50 відсотків; реальний вплив сильно залежить від самого додатку, тому сприймайте такі цифри як сигнал до вимірювання продуктивності ваших власних сторінок, а не як універсальну цифру.
Основна проблема полягає у архітектурних особливостях, а не у помилці певної бібліотеки: обчислення стилів відбувається у браузері, а не під час створення проекту. Це означає, що сам двигун стилізації входить до вашого пакету JavaScript, тож браузеру потрібно обробити більше коду перед тим, як сторінка стане інтерактивною, а процес вставки стилів конкурує з процесом відображення за час обробки.
Чому серверні компоненти виявили цю слабкість
React Server Components (RSC) відображаються на сервері та надсилають свої результати до браузера, не включаючи код компонентів як клієнтський JavaScript. Використання CSS у JavaScript у часі виконання залежить від середовища виконання JavaScript, яке відстежує та вставляє стилі під час відображення, а також від контексту React, який не підтримується серверними компонентами. Це створює суперечність із підходом, коли сервер є основою, який використовують такі фреймворки, як Next.js App Router.
На практиці використання styled-components чи Emotion із Server Components означає позначення стилізованих частин вашого дерева компонентів як Client Components за допомогою директиви 'use client', зазвичай разом із додатковою налаштуванням для збору стилів під час серверної обробки. Коли стилізовані примітиви використовуються скрізь, значна частина дерева компонентів опиняється на клієнтській стороні. Це скасовує багато переваг Server Components — а саме менше JavaScript, яке надсилається до браузера, та менше роботи в ньому, лише для підтримки функціональності бібліотеки стилізації. Для багатьох команд такий компроміс не є вигідним.
Альтернативи під час збірки
CSS-in-JS у режимі виконання досяг свого піку приблизно між 2018 та 2023 роками. Сьогодні існує кілька зрілих варіантів, які уникають витрат під час виконання, кожен з яких підходить для різних уподобань команд.
Tailwind CSS як стандартний варіант
Tailwind CSS став стандартним виходним пунктом для нових проектів на React та Next.js. Ви створюєте класи-функції безпосередньо в маркапі, а етап компіляції генерує лише CSS для класів, які ви фактично використовуєте. Не існує механізму стилізації під час виконання, тому результатуючий файл стилів залишається компактним, а оскільки вихідний код — це звичайний CSS, він працює у серверних компонентах без будь-якої додаткової обробки.
CSS Modules для команд, які віддають перевагу звичайному CSS
Якщо ви волієте писати звичайний CSS замість класів-функцій, CSS Modules надають вам імена класів з локальним обмеженням дії без жодних витрат під час виконання. Більшість інструментів для об’єднання коду та фреймворків підтримують їх заздалегідь, тому для їх використання зазвичай не потрібна жодна налаштування.
CSS-in-JS без витрат під час виконання для знайомої моделі створення коду
Бібліотеки на кшталт Panda CSS та Vanilla Extract дозволяють вам продовжувати писати стилі у JavaScript чи TypeScript, так само як це робилося з styled-components, але вони перетворюють усе на статичний CSS під час процесу будування проекту. Ви зберігаєте можливості для створення стилів та типову безпеку, уникаєте навантаження під час виконання та забезпечуєте повну сумісність із Server Components. Основною зміною є те, що стилі мають бути статично аналізованими, тому значення, які змінюються під час виконання, зазвичай виражаються через варіанти чи CSS-власні властивості замість довільних параметрів. Шаблони для перетворення значень JavaScript у CSS-змінні розглянуті в нашому посібнику з CSS-власними властивостями під час виконання.
Вирішення, коли мігрувати
Нові проекти
Для нового проекту сьогодні майже немає причин обирати CSS-in-JS у час виконання. Розумний стандартний варіант:
- Tailwind CSS для більшості проектів.
- CSS Modules, якщо команда віддає перевагу традиційним таблицям стилів.
- Бібліотека CSS-in-JS без часу виконання, якщо ви хочете продовжувати писати стилі на TypeScript, не оплачуючи послуги часу виконання.
Існуючі проекти
Якщо додаток вже створений за допомогою styled-components або Emotion, немає потреби поспішати. Обидві бібліотеки все ще добре працюють у додатках, які рендеруються на клієнті. Міграція стає доцільною тоді, коли ви плануєте перейти на Server Components або коли аналіз показує, що стилізація є значною частиною витрат на рендеринг.
Коли ви все ж таки будете мігрувати, робіть це поступово, по одному компоненту за раз, переходячи на Tailwind або CSS Modules. Компоненти-листи та спільні примітиви, такі як кнопки, є легкими цілями для початку. Обидві системи можуть існувати одночасно під час переходу, але слід стежити за специфічністю та порядком застосування стилів, коли старі та нові стилі існують поруч.
Підсумок
- CSS-in-JS у часі виконання вирішував реальні проблеми, але обчислює стилі на клієнтській стороні, що збільшує розмір пакета та витрачає час на основній смузі обробки.
- Server Components роблять цей витрат більш помітним, оскільки бібліотеки залежать від JavaScript на клієнтській стороні та надсилають стилізовані структури назад на клієнт.
- Tailwind CSS, CSS Modules та бібліотеки без обробки в часі виконання, такі як Panda CSS та Vanilla Extract, генерують статичний CSS під час збирання та природно працюють із Server Components.