Jak budować design systemy, które przetrwają zmiany w webie z Progressive Web Components

Budujesz bibliotekę komponentów na dużą skalę? Na pewno znasz ten konflikt. Web components dają prawdziwą niezależność od frameworków. Żadnego lock-inu. Ale w praktyce? Przesunięcia layoutu przed załadowaniem JS, problemy z dostępnością przez Shadow DOM i koszmary z SSR.

Problem? Za bardzo je komplikujemy.

Paradoks web components

Wyobraź sobie: zespół wybiera web components na design system. Tworzą Custom Elements, pakują ciężki framework. Efekt? Kilobajty JS-u tylko po to, by pokazać przycisk. HTML przychodzi pierwszy, potem JS przebudowuje całość. Użytkownik widzi flash bez stylów. Czytniki ekranu gubią się w Shadow DOM. SSR to męka.

To nie wina web components. To nasza wina – złe podejście do budowy.

A co jeśli zaczniemy od tyłu?

Najlepsze pomysły wydają się oczywiste po fakcie. A gdyby komponenty działały najpierw jako czysty HTML i CSS? JavaScript tylko jako dodatek?

To sedno Progressive Web Components – filozofii budowy (nie frameworka). Dwa warstwy:

Warstwa bazowa: sam HTML i CSS. Działa od razu w przeglądarce. Bez JS. Treść widoczna, style na miejscu, stabilność gwarantowana.

Warstwa ulepszeń: JS dodaje interakcje, eventy i stany reaktywne. Ale tylko tam, gdzie trzeba.

Trzy typy komponentów

Nie każdy komponent musi być taki sam. Progressive Web Components dzielą się na trzy:

Composite Components owijają istniejący HTML. Na przykład dropdown na bazie <select> czy tabs z list. Light DOM zapewnia dostępność i kompatybilność z frameworkami.

Primitive Components samodzielne. Date picker, slider czy kalendarz. HTML renderuje się upfront, JS dodaje magię później.

Declarative Shadow DOM Components z natywnym Shadow DOM, ale z SSR. Idealne do enkapsulacji stylów bez strat.

Wybierasz, co pasuje. Żadnych sztywnych reguł – tylko filozofia warstw.

Luka między teorią a praktyką

Rozumiesz ideę? Super. Ale wdrożyć to w dziesiątkach komponentów? Tu wchodzą detale.

Biblioteka musi ogarniać:

• Synchronizację props i atrybutów między frameworkami
• Delegację eventów bez Shadow DOM
• Hydrację bez niepotrzebnego re-renderu
• Scoped CSS bez JS
• Dostępność od zera
• SSR bez sztuczek po stronie serwera

Większość bibliotek każe ci to robić samemu. Kończysz z boilerplate'em, a "progressive" znika – JS staje się obowiązkowy.

Nowe myślenie o architekturze

Progressive podejście zmienia priorytety:

Najpierw HTML. Stan początkowy to semantyczny HTML, który działa od razu. Styluj CSS-em. Dbaj o dostępność. JS tylko na interakcje.

JS opcjonalny. Formularz z walidacją działa bez JS. Menu nawigacyjne dostępne w HTML-u. Ulepszenia to bonus, nie konieczność.

Opieraj się na platformie. Custom Elements, Shadow DOM (gdy trzeba), Slots, Declarative Shadow DOM – to natywne ficzerki. Buduj z nimi.

Wsparcie dla frameworków. HTML-first działa wszędzie: React, Vue, Angular, Svelte czy vanilla JS. Bez adapterów.

SSR z natury. HTML i CSS renderują się na serwerze bez wysiłku. Dla stanów reaktywnych – proste narzędzia.

Jaki rozmiar ma mieć biblioteka?

Pytanie kluczowe: ile JS-u potrzebuje design system?

Popularne biblioteki? 50KB+. Progressive Web Components? Cały overhead to 2.6KB. Reszta to twoje komponenty.

To realny wpływ na perf. Mniej JS = szybszy download, parsowanie, wykonanie. Na mobile 3 sekundy zamiast 8 do interakcji.

SSR bez bólu głowy

Zwykle SSR wymaga dedykowanego kodu po serwerze. Progressive Web Components odwracają: HTML/CSS-first renderuje się sam.

Composite i Declarative? Zero specjalnego kodu. Primitive z reaktywnością? HTML na serwerze, hydratacja po kliencie.

Koniec z głównym bólem web components w SSR.

Biblioteki, które nie zestarzeją się szybko

Budujesz design system? Progressive Web Components dają rzadką rzecz: pełną przenośność bez strat.

Nie jesteś uwiązany do Reacta czy Vue. Komponenty działają dziś i za trzy lata, z nowym frameworkiem.

Wymaga dyscypliny. Ograniczasz JS. Inwestujesz w semantyczny HTML i przemyślany CSS. Ale zysk? Komponenty naprawdę reusable, szybkie i dostępne.

Podsumowanie

Web components nie zawodzą. My je psuliśmy, traktując jak frameworki JS, a nie HTML. Progressive Web Components wracają do korzeni: web platforma first, warstwy z głową. Małe, przenośne, performant.

Dla zespołów na dużą skalę to mocna pozycja. Warto spróbować.