Opuściec CSS w JS w czasie wykonywania: komponenty serwerowe i style w czasie budowania

Przez kilka lat biblioteki CSS-in-JS działające w czasie wykonywania, takie jak styled-components i Emotion, były najpopularniejszym sposobem stylizacji komponentów React: style ograniczone do konkretnego komponentu, wartości określane przez propsy oraz brak kolizji nazw klas na poziomie globalnym. Od tamtej pory ekosystem przesunął się w stronę stylów generowanych w czasie budowania aplikacji, co jest motywowane przede wszystkim wymogami dotyczącymi wydajności oraz rozwojem React Server Components. Ten artykuł wyjaśnia, co się zmieniło, porównuje główne alternatywy i podaje praktyczną zasadę dotyczącą tego, kiedy warto migrować istniejącą bazę kodu, a kiedy lepiej ją pozostawić w spokoju.

Wiele zespołów, zarówno dużych, jak i małych, już przeniosło nowe projekty z stylizacji w czasie wykonywania, a powody te są istotne przed podjęciem decyzji o wyborze konkretnej metody.

Koszt generowania stylów w przeglądarce

Biblioteki typu CSS-in-JS działające w czasie wykonywania generują kod CSS podczas uruchamiania aplikacji. W miarę renderowania komponentów biblioteka przekształca definicje stylów (włączając wartości zależne od atrybutów) w reguły CSS, tworzy nazwy klas i wstrzykuje tagi <style> do dokumentu. Te operacje odbywają się na wątku głównym, na urządzeniu użytkownika. Opublikowane testy porównawcze z statycznym CSS wskazują na spowolnienie renderowania o 20 do 50 procent; rzeczywisty wpływ zależy silnie od aplikacji, dlatego należy traktować takie wartości jako sygnał do pomiarów na własnych stronach, a nie jako uniwersalną wartość.

Podstawowym problemem jest kwestia architektury, a nie błąd w konkretnej bibliotece: obliczanie stylów odbywa się w przeglądarce, a nie podczas budowania aplikacji. Oznacza to, że sam silnik stylizacji jest zawarty w pliku JavaScript, przeglądarca musi przetworzyć i wykonać więcej skryptów, zanim strona stanie się interaktywna, a wstawianie stylów konkuruje z procesem renderowania o dostęp do zasobów czasowych.

Dlaczego komponenty serwerowe ujawniły tę słabość

React Server Components (RSC) renderują się na serwerze i wysyłają swoje wyniki do przeglądarki, nie dostarczając kodu komponentu jako JavaScriptu klienckiego. CSS-in-JS w czasie wykonywania polega na użyciu środowiska JavaScript, które śledzi i wstrzykuje style podczas renderowania, a także opiera się na kontekście React, którego komponenty serwerowe nie obsługują. To stawia go w sprzeczności z modelem „serwer na pierwszym miejscu” stosowanym przez takie frameworki jak Next.js App Router.

'use client', zazwyczaj w połączeniu z dodatkowymi ustawieniami do zbierania stylów podczas renderowania na serwerze. Gdy stylizowane elementy bazowe są używane wszędzie, duża część drzewa komponentów trafia na stronę klienta. To unieważnia wiele z zalet Server Components, mianowicie mniejszą ilość JavaScript wysyłaną do przeglądarki oraz mniej pracy w niej, wyłącznie po to, by biblioteka do stylizacji funkcjonowała. Dla wielu zespołów taka kompromis nie jest warte zachodu.

Tailwind CSS stał się standardowym punktem wyjścia dla nowych projektów React i Next.js. Klasы utility tworzy się bezpośrednio w kodzie markup, a etap budowania generuje tylko CSS dla klas, których faktycznie używa się. Nie ma żadnego silnika stylizacji w czasie wykonywania, co sprawia, że plik z regułami stylizacji pozostaje niewielki, a ponieważ wynik to zwykły CSS, działa on w komponentach serwerowych bez żadnych dodatkowych działań.

Modyuły CSS dla zespołów preferujących zwykły CSS

Jeśli wolisz pisać zwykły CSS zamiast klas utility, modyuły CSS umożliwiają używanie nazw klas o zasięgu lokalnym bez żadnych kosztów w czasie wykonywania. Są one natywnie obsługiwane przez większość narzędzi do pakowania i frameworków, więc ich wdrożenie zazwyczaj nie wymaga żadnej konfiguracji.

CSS-in-JS bez kosztów w czasie wykonywania dla znajomego modelu tworzenia

Biblioteki takie jak Panda CSS i Vanilla Extract umożliwiają utrzymywanie stylów w JavaScript lub TypeScript, podobnie jak to było możliwe z styled-components, ale one wyodrębniają wszystko do statycznego CSS podczas procesu budowania. Zachowujesz doświadczenie tworzenia stylów oraz bezpieczeństwo typów, bez dodatkowego obciążenia w czasie wykonywania, przy pełnej kompatybilności z Server Components. Główną różnicą jest to, że style muszą być możliwe do statycznej analizy, więc wartości zmieniające się w czasie wykonywania są zazwyczaj reprezentowane za pomocą wariantów lub domyślnych właściwości CSS zamiast dowolnych propów. Wzorce łączenia wartości JavaScript z zmiennymi CSS są omówione w naszym przewodniku po domyślnych właściwościach CSS w czasie wykonywania.

Decyzja o migracji

Nowe projekty

W przypadku nowego projektu obecnie nie ma większych powodów, by wybierać CSS-in-JS w czasie wykonywania. Rozsądny standard to:

• Tailwind CSS dla większości projektów.
• CSS Modules, jeśli zespół woli tradycyjne pliki stylów.
• Biblioteka CSS-in-JS bez konieczności wykonywania w czasie rzeczywistym, jeśli chcesz nadal pisać style w TypeScript bez ponoszenia kosztów związanych z jej działaniem w czasie wykonywania.

Projekty istniejące

W przypadku aplikacji już zbudowanej przy użyciu styled-components lub Emotion nie ma potrzeby pośpiechu. Obie te biblioteki nadal dobrze funkcjonują w aplikacjach renderowanych po stronie klienta. Migracja staje się opłacalna, gdy planujesz przejść na Server Components lub gdy analiza wydajności pokazuje, że stylizacja stanowi znaczącą część kosztów renderowania.

Gdy przeprowadzasz migrację, rób to stopniowo, po jednym komponencie naraz, przechodząc na Tailwind lub CSS Modules. Komponenty jednostkowe oraz wspólne elementy takie jak przyciski to łatwe cele na początek. Oba systemy mogą współistnieć podczas przejścia, ale należy uważać na specyficzność i kolejność stylów, gdy stare i nowe style istnieją obok siebie.

Podsumowanie

• CSS-in-JS w czasie wykonywania rozwiązywało rzeczywiste problemy, ale oblicza style na stronie klienta, co zwiększa rozmiar pliku i zużywa czas w głównej wątku.
• Komponenty serwerowe sprawiają, że ten koszt staje się bardziej widoczny, ponieważ biblioteki polegają na JavaScriptie strony klienta i wysyłają stylizowane struktury z powrotem na klienta.
• Tailwind CSS, CSS Modules oraz biblioteki bez obliczeń w czasie wykonywania, takie jak Panda CSS i Vanilla Extract, generują statyczny CSS w momencie budowania i naturalnie współpracują z komponentami serwerowymi.

Dla nowych projektów wybierz podejście oparte na czasie budowania; w przypadku istniejących aplikacji migruj stopniowo i tylko wtedy, gdy komponenty serwerowe lub pomiary wydajności dostarczą konkretnego powodu.

Literatura pokrewna

• Zrozumienie komponentów Cache i częściowego prefetchingu w Next.js 16.3 — Wyjaśnia, jak funkcja Instant Navigations w Next.js 16.3 wykorzystuje wspólne szkielety tras oraz wyraźne decyzje dotyczące strumieniowania, aby aplikacje renderowane na serwerze działały natychmiastowo.
• React Server Components: Architektura stojąca za renderowaniem bez pliku bundle — Poznaj uzasadnienie istnienia React Server Components, od rozmiaru pliku bundle i problemów z procesem renderowania po granicę między serwerem a klientem oraz zawartość pakietów RSC.
• Przeglądarka, serwer czy czas budowania: mapa decyzji dotycząca architektur frontendu — Dowiedz się, jak SSG, SSR, streaming, Server Components, BFFs, renderowanie na brzegu, modularne monolity oraz mikrofrontendy odpowiadają na jedno pytanie: gdzie powinna odbywać się praca?