TL;DR

Świat stylowania aplikacji webowych przeszedł znaczącą transformację: od monolitycznych bibliotek do modułowych, elastycznych systemów
Tailwind przestał być tylko „alternatywnym CSS” i stał się standardem branżowym, mimo wprowadzenia kontrowersyjnej składni z nawiasami
CSS-in-JS praktycznie „umarł” – teraz style są generowane w czasie budowy, nie w runtime’ie
shadcn zrewolucjonizował sposób tworzenia bibliotek komponentów, łącząc najlepsze cechy Tailwinda i Radix UI
Komponenty shadcn są kopiowane do kodu projektu, co zapewnia pełną kontrolę, możliwość modyfikacji i lepszą utrzymywalność
Nawet wielkie biblioteki jak MUI (dawniej Material UI) zmieniają podejście w kierunku bardziej modułowych rozwiązań
Przyszłość należy do rozwiązań, które oferują zarówno łatwość wdrożenia, jak i elastyczność w dłuższej perspektywie

Ta notatka zawiera najważniejsze wnioski z prezentacji Theo dotyczącej aktualnego stanu rozwiązań stylowania w 2025 roku. To kolejna część mojej serii, gdzie dzielę się najciekawszymi informacjami z wartościowych materiałów, do których warto wracać.

Jak zauważa Theo w swojej prezentacji: „Istnieje więcej rozwiązań do stylowania aplikacji webowych niż kiedykolwiek wcześniej, ale jednocześnie proces decyzyjny stał się zarówno łatwiejszy, jak i trudniejszy”. To doskonale oddaje złożoność ekosystemu w 2025 roku.

Trzy typy bibliotek UI – klasyfikacja, która wciąż ma sens

Theo przypomina, że w swoim poprzednim materiale (sprzed prawie 3 lat) podzielił biblioteki UI na trzy kategorie, które wciąż mają sens:

1. Rozszerzenia CSS

Takie jak Sass, Less i Tailwind – narzędzia, które rozszerzają możliwości CSS, ale nie zmieniają jego fundamentalnego działania.

2. Biblioteki zachowań (Behavioral libraries)

Na przykład Headless UI, Radix UI, czy React Aria – skupiają się na funkcjonalności, dostępności i interakcjach, ale nie narzucają stylów.

3. Systemy stylów

Takie jak Tailwind UI czy Bootstrap – oferują gotowe style i komponenty wizualne.

Tailwind – ewolucja i kontrowersje

Tailwind zyskał ogromną popularność, ale też znacząco ewoluował. Theo zauważa: „Tailwind jest masywną wygraną dla dużych projektów z wieloma komponentami”. Dlaczego? Ponieważ rozwiązuje fundamentalny problem konfliktu między systemem komponentów a CSS.

W tradycyjnym podejściu musiałeś definiować komponenty w dwóch miejscach – w kodzie JavaScript i w CSS – co prowadziło do konfliktów i trudności w utrzymaniu. Tailwind rozwiązał ten problem.

Interesującą obserwacją Theo jest to, że Tailwind początkowo miał być ściśle ustrukturyzowanym systemem z ograniczonymi wartościami (np. p-1, p-2, p-4, p-6), co miało wymuszać spójność. Jednak z czasem wprowadzono składnię z nawiasami (np. p-[15px]), co zdaniem Theo „zabija aspekt systemu stylów” w Tailwindzie, przesuwając go bardziej w stronę „rozszerzenia CSS”.

Jak podkreśla Theo: „Teraz można robić cokolwiek, co zabija ścisłość systemu… Wcześniej był to system z bardzo ścisłymi regułami, a teraz mamy dziwne, ezoteryczne zasady jak 'wszystko co jest wielokrotnością 0,25 jest dobre'”.

Śmierć CSS-in-JS i narodziny nowego podejścia

Theo nie owija w bawełnę: „CSS-in-JS nie żyje”. Główna zmiana polega na tym, że obecnie style nie są generowane przez JavaScript w czasie działania aplikacji, ale podczas budowy jako pliki CSS. W runtime następuje tylko zamiana nazw klas na elementach.

To fundamentalna zmiana w porównaniu z wcześniejszymi rozwiązaniami, gdzie style były dynamicznie generowane w przeglądarce. Theo ostro krytykuje twórców, którzy próbują podtrzymać narrację o przydatności CSS-in-JS, nazywając ich teorie „szalonymi teoriami spiskowymi”.

Nowe podejścia inspirowane Tailwindem

Theo wymienia kilka interesujących projektów inspirowanych sukcesem Tailwinda:

Panda CSS – nowoczesna alternatywa
Windi CSS (obecnie porzucony projekt)
UnoCSS – bardzo podobny do Tailwinda
Tokamachi – ciekawe podejście oparte na typach

Stylex – odpowiedź Facebooka na problemy z Tailwindem

Theo poświęca sporo uwagi Stylexowi – rozwiązaniu stworzonym przez Facebooka, a konkretnie przez Namana, którego nazywa „jednym z najbardziej utalentowanych ludzi w przestrzeni stylów i webdevu”.

Stylex powstał, ponieważ Facebook miał specyficzne problemy, których Tailwind nie rozwiązywał. Theo poleca stronę „Thinking in Stylex”, która „przeprogramowała jego mózg w kwestii podejścia do stylów”. Najciekawsze jest to, że Stylex docenia zalety Tailwinda, ale jednocześnie rozpoznaje, że jego konstrukcja nie może dobrze działać w skali Facebooka.

Co więcej, Naman pracuje nad kompilatorem, który przekształci Tailwinda w Stylex. To pokazuje, jak różne podejścia mogą się uzupełniać, zamiast ze sobą konkurować.

Narodziny shadcn – punktu zwrotnego

Według Theo, shadcn całkowicie zrewolucjonizował sposób, w jaki tworzymy i używamy bibliotek komponentów. Zamiast być kolejną biblioteką, którą po prostu instalujesz, shadcn przyjmuje inne podejście:

Inicjujesz shadcn w swoim projekcie, co tworzy plik konfiguracyjny
Wybierasz potrzebny komponent (np. alert, przycisk)
Uruchamiasz komendę, która kopiuje kod tego komponentu do Twojego projektu
Komenda instaluje również wszelkie potrzebne zależności (np. elementy Radix UI)

Jak wyjaśnia Theo: „To, co sprawia, że shadcn jest tak odmienny, to nie jedna rzecz, ale kilka. W przeciwieństwie do innych rozwiązań typu 'wszystko w jednym’, które dają ci komponenty, shadcn nie zastępuje Tailwinda, Radixa czy Bootstrapa. On używa Radixa i Tailwinda.”

Dlaczego shadcn wygrał?

Theo zwraca uwagę na kilka kluczowych zalet podejścia shadcn:

Pełna kontrola – kod jest w Twoim repozytorium, więc możesz go dowolnie modyfikować
Brak lock-inu – nie jesteś zależny od jednej biblioteki
Modułowość – używasz tylko tego, czego potrzebujesz
Aktualizacje granularne – możesz aktualizować poszczególne komponenty lub ich zależności niezależnie

Theo podkreśla: „To takie niesamowite, że coś takiego może być zbudowane z shadcn i wyglądać zupełnie inaczej. To, co się zmienia, to nie 10 linii kodu, które opakowują prymityw checkbox z Radix UI – to nie tam jest złożoność.”

Theo podważa również częsty argument o trudności utrzymania kodu: „Część, która się zmienia, to nie te 10 linii kodu, które opakowują prymityw checkbox z Radix UI. To nie tam jest złożoność. Części, które muszą się zmieniać, to zależności, które można po prostu zaktualizować.”

Porównanie głównych podejść do stylowania

Rozwiązanie	Zalety	Wady	Najlepsze zastosowanie
Tailwind	Eliminuje konflikty CSS z komponentami; Wysoka wydajność; Wspiera komponenty; Promuje spójność	Z nawiasami traci część zalet systemowych; Wysoka krzywa uczenia; Kod może być trudny do czytania	Duże projekty z wieloma komponentami
Material UI / MUI	Gotowe do użycia komponenty; Spójny wygląd	Trudne dostosowanie; Potencjalne problemy z aktualizacjami; Opinie stylów mogą się szybko zestarzeć	Szybkie prototypowanie; Projekty, gdzie wygląd Google jest akceptowalny
shadcn	Modułowość; Kod w Twoim repozytorium; Łatwa kastomizacja; Dobre domyślne style	Więcej pakietów do zarządzania; Więcej kodu w repozytorium	Projekty wymagające elastyczności i kontroli
Stylex	Wydajność w dużej skali; Dobra typizacja; Dobre dla SSR	Mniejsza społeczność; CSS-in-JS (choć generowany w czasie budowy)	Projekty w dużej skali podobne do Facebooka
Radix UI	Doskonała dostępność; Skupienie na zachowaniu; Separacja stylów od zachowania	Wymaga własnych stylów; Więcej pracy przy starcie	Projekty z wysokimi wymaganiami dostępności

Reakcja rynku – wszyscy podążają za trendami

Jednym z najciekawszych spostrzeżeń Theo jest to, jak rynek reaguje na sukces shadcn. Nawet MUI (dawniej Material UI), które było jedną z najpopularniejszych monolitycznych bibliotek komponentów, zaczyna przechodzić w stronę bardziej modułowego podejścia z projektami jak Base UI:

„Base UI to biblioteka dostępnych komponentów React bez stylów. To naprawdę fajne, że ludzie z MUI w końcu przyznali, że rozwiązania typu 'wszystko w jednym’ są złe i nie powinny być tym, do czego wszyscy dążymy.”

Podobnie Chakra UI, która według Theo „zniknęła z radaru”, również zmienia podejście: „W Chakra V3 jednoczymy nasz ekosystem narzędzi, łącząc bibliotekę headless Arc UI z API stylizacji w Panda CSS, a następnie używając Parkui jako systemu designu.”

Theo komentuje to krótko: „Są po prostu nową wersją shadcn z gorszymi komponentami”.

Przyszłość stylowania – modułowość zwycięża

Główny wniosek, jaki Theo wyciąga, to triumf modułowości nad monolitycznymi rozwiązaniami. Jak sam mówi:

„Jako branża zaakceptowaliśmy, że rozwiązanie, które udaje, że rozwiąże wszystkie te problemy, nie jest wystarczająco dobre, ponieważ będziemy mieć problemy z dowolnym obszarem i chcemy najlepszych rozwiązań dla różnych obszarów.”

Przyszłość należy do elastycznych, modułowych systemów, które można łatwo dostosować do zmieniających się potrzeb. Theo jest szczególnie podekscytowany tym, że branża w końcu uznała, że:

„Radix jest naprawdę dobry, Tailwind jest naprawdę dobry, a Twoje style są oddzielną rzeczą. I zamiast udawać, że wszystkie te rzeczy to jeden pakiet, który powinieneś zainstalować, powinniśmy je traktować oddzielnie.”

Wnioski praktyczne

Z perspektywy Theo, główne wnioski są następujące:

Modułowość zawsze wygrywa z monolitycznymi rozwiązaniami – „Modułowość zawsze jest łatwiejsza w utrzymaniu. Zawsze. I nie pojmuję, jak ktokolwiek może widzieć to inaczej.”
Komponenty są jedynym sensownym sposobem na budowanie aplikacji webowych w skali – „Teraz, gdy zaakceptowaliśmy, że kaskada to bałagan dla utrzymania, a komponenty są jedynym realnym sposobem na dostarczanie aplikacji webowych w skali, powoli rozmontowaliśmy i odbudowaliśmy świat wokół nich.”
Najlepsze rozwiązania łączą łatwość rozpoczęcia z elastycznością rozwoju – „Ta równowaga między 'pstryknij palcami, masz bibliotekę komponentów’ a 'chcesz to zmienić? po prostu to zmień’ to coś, co musiałeś robić sam wcześniej, a teraz już nie musisz.”

Praktyczne implikacje według Theo

Theo zwraca uwagę, że przejście z monolitycznych bibliotek jak Material UI na modułowe rozwiązania jak shadcn znacząco usprawnia pracę deweloperów. Podkreśla, że zamiast walczyć z systemem stylów, można skupić się na budowaniu funkcjonalności.

Szczególnie ceni fakt, że gdy klient chce zmienić wygląd komponentu, można to zrobić bez obawy o wpływ na inne części aplikacji. Jak sam mówi: „Modułowość jest zawsze łatwiejsza w utrzymaniu. Zawsze. I nie pojmuję, jak ktokolwiek może widzieć to inaczej.”

Reakcja rynku – wszyscy podążają za trendami

Jednym z najciekawszych spostrzeżeń Theo jest to, jak rynek reaguje na sukces shadcn. Nawet MUI (dawniej Material UI), które było jedną z najpopularniejszych monolitycznych bibliotek komponentów, zaczyna przechodzić w stronę bardziej modułowego podejścia z projektami jak Base UI:

„Base UI to biblioteka dostępnych komponentów React bez stylów. To naprawdę fajne, że ludzie z MUI w końcu przyznali, że rozwiązania typu 'wszystko w jednym’ są złe i nie powinny być tym, do czego wszyscy dążymy.”

Podobnie Chakra UI, która według Theo „zniknęła z radaru”, również zmienia podejście: „W Chakra V3 jednoczymy nasz ekosystem narzędzi, łącząc bibliotekę headless Arc UI z API stylizacji w Panda CSS, a następnie używając Parkui jako systemu designu.”

Theo komentuje to krótko: „Są po prostu nową wersją shadcn z gorszymi komponentami”.

Polecane materiały do pogłębienia tematu

Theo wspomina w swojej prezentacji o kilku wartościowych zasobach:

„Refactoring UI” – książka twórców Tailwinda, którą napisali przed stworzeniem tego narzędzia. Theo komentuje: „To świetna lektura. Jako deweloper słaby w designie, pomogła mi ogromnie z moim modelem mentalnym dotyczącym systemów designu i dobrego języka projektowego.”
„Thinking in Stylex” – strona internetowa, którą Theo opisuje jako „przeprogramowującą mój mózg w kwestii myślenia o stylach”. Wyjaśnia ona, jak Facebook podszedł do problemu stylowania w dużej skali.

Źródła i dodatkowe materiały

Thinking in Stylex – strona polecana przez Theo jako rewolucyjna dla zrozumienia nowoczesnego podejścia do stylów
shadcn/ui – oficjalna strona shadcn
Radix UI – doskonała biblioteka komponentów headless
Tailwind CSS – oficjalna strona Tailwind CSS
Base UI – nowe podejście MUI do komponentów bez stylów

Źródło: „A breakdown of style solutions for 2025” – prezentacja Theo, kwiecień 2025

Tag: Modulowosc

Rozwiązania stylowania w 2025 roku #EN41