Panda CSS - czym jest i kiedy warto go użyć?

Każda strona i aplikacja potrzebuje stylów: kolorów, odstępów, czcionek, zachowania na telefonie. Sposób, w jaki zespół je zapisuje, nie jest widoczny dla klienta, ale wpływa na szybkość strony, spójność wyglądu i to, ile kosztuje każda zmiana w interfejsie. Panda CSS to jedno z narzędzi do pisania stylów, które w ostatnich dwóch latach zyskało sporo uwagi. Poniżej wyjaśniamy, czym jest i kiedy warto go użyć.

Krótko: Panda pozwala programistom pisać style w TypeScripcie, z podpowiedziami i kontrolą błędów, a do przeglądarki trafia zwykły, lekki CSS. Łączy wygodę jednego podejścia z wydajnością drugiego.

Skąd wziął się Panda CSS

Przez lata popularnym sposobem stylowania aplikacji w React było CSS-in-JS, czyli pisanie stylów w tym samym pliku co kod komponentu. Najbardziej znaną biblioteką tego typu jest styled-components. Programiści to lubili: style są obok przycisku, którego dotyczą, można je zmieniać w zależności od stanu, nie ma konfliktów nazw. Miało to jednak koszt. Klasyczne CSS-in-JS generuje style w przeglądarce użytkownika, w trakcie działania strony. To dodatkowy kod do pobrania i dodatkowa praca dla telefonu. Zalety i wady CSS-in-JS były przez lata tematem dyskusji, ale dopóki aplikacja działała szybko, większość zespołów to akceptowała.

Sytuację zmieniły React Server Components, czyli komponenty renderowane na serwerze, bez wysyłania ich kodu do przeglądarki. Biblioteki generujące style w przeglądarce nie pasują do tego modelu. W marcu 2025 r. styled-components przeszedł w tryb utrzymania: poprawki bezpieczeństwa tak, nowe funkcje nie. Zespoły z dużymi aplikacjami zaczęły szukać następcy.

Pandę stworzył zespół odpowiedzialny za bibliotekę komponentów Chakra UI, dobrze znaną programistom Reacta. Wersja 1.0 ukazała się w sierpniu 2025 r. Projekt jest open source na licencji MIT.

Panda CSS - czym jest i jak działa

Panda to narzędzie, które czyta kod aplikacji w trakcie jej budowania, znajduje wszystkie użyte style i zapisuje je do jednego pliku CSS. W przeglądarce nie działa już nic. Użytkownik dostaje gotowe klasy, tak jakby zespół napisał CSS ręcznie. To podejście nazywa się zero-runtime CSS-in-JS. „Zero-runtime” oznacza, że w czasie działania strony nie ma żadnej pracy związanej ze stylami. Dla właściciela produktu przekłada się to na mniej kodu do pobrania i brak konfliktu z React Server Components. Druga cecha to typowanie. Panda generuje opisy wszystkich dostępnych stylów dla TypeScriptu, więc edytor podpowiada programiście kolory i odstępy z systemu projektowego, a literówkę zaznacza na czerwono, zanim kod trafi do przeglądarki.

Panda nie jest przywiązana do jednego frameworka. Według dokumentacji Panda CSS działa z Next.js, Vue.js, Nuxt.js, Astro, Svelte i projektami budowanymi w Vite. Dołącza się ją przez PostCSS, czyli narzędzie przetwarzające CSS podczas budowania, albo przez własne narzędzie wiersza poleceń.

Pięć pojęć, które usłyszysz od zespołu

Kiedy programiści proponują Pandę, w rozmowie pojawia się kilka słów, które dla osoby spoza frontendu brzmią obco. Wyjaśniamy je po kolei.

Tokeny

Design tokeny to nazwane wartości wizualne: kolor „brand-500” czy odstęp „md”. Definiuje się je raz w konfiguracji Pandy i używa w całej aplikacji. Zmiana koloru marki to zmiana jednej linijki, a nie szukanie wartości w setkach plików. Tokeny mogą też mieć dwa warianty, jasny i ciemny, co bardzo ułatwia wprowadzenie trybu ciemnego.

Recipes

Recipe, czyli przepis, opisuje komponent z jego wariantami. Przycisk ma rozmiary „mały”, „średni”, „duży” i warianty „główny” oraz „drugorzędny”. Recipe zbiera wszystkie te kombinacje w jednym miejscu. Programista wybiera wariant, zamiast składać wygląd z pojedynczych stylów.

Patterns

Patterns to gotowe układy: stos elementów jeden pod drugim, wiersz z odstępami, siatka, wyśrodkowanie. Zamiast pisać za każdym razem ten sam zestaw reguł, zespół używa nazwanego wzorca.

Style props

Style props pozwalają ustawiać styl bezpośrednio jako właściwość komponentu, na przykład kolor tła czy margines. To wygodne przy drobnych poprawkach i znane z Chakra UI, a w Pandzie działa bez kosztu w przeglądarce.

Atomic CSS

Panda generuje tak zwany atomic CSS: każda reguła, na przykład „kolor tekstu: szary”, trafia do pliku wynikowego raz, jako osobna klasa. Gdy sto komponentów używa tego samego koloru, w CSS jest jedna reguła, nie sto. Dzięki temu plik stylów rośnie wolniej niż aplikacja.

Panda CSS a Tailwind

Najczęstsze pytanie dotyczy Tailwind CSS. Oba narzędzia generują atomic CSS podczas budowania i oba usuwają nieużywane style. Różnią się sposobem pisania. W Tailwindzie styl zapisuje się jako długi ciąg krótkich klas bezpośrednio w HTML, na przykład „p-4 bg-blue-500 rounded-lg”. To szybkie, ale przy złożonych komponentach linijki z klasami robią się bardzo długie i trudne do czytania. W Pandzie styl to obiekt w TypeScripcie, z nazwami właściwości jak w zwykłym CSS. Jest więcej pisania, ale też więcej kontroli i lepsze podpowiedzi.

Tailwind ma znacznie większy ekosystem gotowych bibliotek komponentów i szablonów, a do tego więcej programistów, którzy go znają. Podejście utility-first ma swoje atuty i ograniczenia na tle innych frameworków CSS, a największym ograniczeniem jest czytelność przy rozbudowanych komponentach. Panda wygrywa tam, gdzie zespół buduje własny, rozbudowany system komponentów z wieloma wariantami.

W praktyce wybór zależy często od tego, co zespół zna i jak chce pracować, a nie od różnic w wydajności. Obie drogi dają szybką stronę.

Kiedy warto użyć Panda CSS

Panda sprawdza się najlepiej w kilku typach projektów:

• aplikacja ma własny design system z tokenami i komponentami w wielu wariantach,
• zespół przechodzi ze styled-components lub Emotion i chce zachować styl pracy, w którym style żyją w kodzie komponentu,
• projekt korzysta z React Server Components w Next.js i potrzebuje rozwiązania, które z nimi współpracuje,
• kilka aplikacji ma dzielić ten sam wygląd, na przykład panel klienta i panel administracyjny,
• firma chce, żeby kolory i odstępy z projektu w Figmie przechodziły do kodu jako tokeny, bez ręcznego przepisywania.

Najwięcej zyskują duże, długo rozwijane produkty, w których interfejs liczy setki ekranów. Tam spójność wyglądu i łatwość wprowadzania zmian mają realną wartość. Panda dobrze współpracuje też z Storybookiem, w którym zespoły dokumentują komponenty i ich warianty.

Kiedy lepiej wybrać coś innego

Mała strona firmowa czy landing page nie potrzebuje Pandy. Konfiguracja tokenów i recipes to praca, która zwraca się dopiero przy większej skali. Prosty CSS albo Tailwind zrobią to samo szybciej. Nie ma też sensu zmieniać rozwiązania, które działa. Aplikacja w Tailwindzie, z którego zespół jest zadowolony, nie zyska na przejściu na Pandę nic, co uzasadniałoby koszt. Ostrożności wymaga wybór, gdy projekt opiera się na gotowej bibliotece komponentów z własnym systemem stylów, takiej jak Material UI. Łączenie dwóch systemów stylowania w jednym projekcie zwykle kończy się chaosem. Wtedy lepiej trzymać się tego, co dostarcza biblioteka. Ostatnia kwestia to ludzie. Pandę zna mniej programistów niż Tailwinda. Przy zespole, który często się zmienia albo jest uzupełniany przez zewnętrznych wykonawców, ma to znaczenie przy wdrażaniu nowych osób.

Ile kosztuje przejście na Panda CSS

W nowym projekcie Panda nie generuje dodatkowych kosztów poza czasem na przygotowanie konfiguracji: tokenów, podstawowych recipes i wzorców. To zwykle od kilku dni do dwóch tygodni pracy, zależnie od tego, czy istnieje gotowy design system w Figmie, czy trzeba go dopiero uporządkować.

Migracja istniejącej aplikacji to inna skala. Przejście ze styled-components oznacza przepisanie stylów każdego komponentu. Najczęściej robi się to stopniowo: nowe komponenty powstają w Pandzie, stare są przenoszone przy okazji innych zmian, a przez pewien czas oba systemy działają obok siebie. Dla średniej aplikacji to praca rozłożona na kilka tygodni do kilku miesięcy.

Na czas wpływa przede wszystkim liczba komponentów i stopień uporządkowania obecnych stylów. Najdłużej przenosi się style z dużą ilością logiki zależnej od stanu aplikacji. Takie przejście najlepiej zaplanować razem z innymi zmianami w ramach migracji aplikacji do nowszych technologii, na przykład przejściem na nowszą wersję Next.js.