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
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.