Byg designsystemer, der holder til fremtiden med progressive web components

Har du nogensinde bygget store komponentbiblioteker til virksomheder? Så kender du spændingen. Web components giver ægte fleksibilitet – de virker overalt uden at binde dig til ét framework. Men de medfører ofte problemer: layout-skift, før JavaScript loader, accessibility-faldgruber med Shadow DOM og krångel med server-side rendering.

Problemet? Vi har gjort det alt for kompliceret.

Web components-paradokset

Et typisk scenarie: Holdet vælger web components til designsystemet. De laver Custom Elements, loader et tungt framework og sender pludselig massevis af JavaScript med for at vise en simpel knap. HTML'en kommer først, så overtager JS og genskaber alt. Brugere ser ustylet indhold blinke forbi. Skærmlæsere forvirres af Shadow DOM. SSR bliver en hovedpine.

Det er ikke web components' skyld. Det er vores tilgang.

Vend det om – start med HTML

De smarteste løsninger virker oplagte bagefter. Forestil dig komponenter, der viser semantisk HTML og CSS fra starten. JavaScript kommer til som et ekstra lag.

Det er essensen i progressive web components – en filosofi, ikke et framework. Komponenterne har to lag:

Basislaget er ren HTML og CSS. Det renderer øjeblikkeligt uden JS. Indhold vises, styles gælder, siden er stabil.

Forbedringslaget er JavaScript til interaktion, events og reaktiv state – kun hvis det skal bruges.

Tre typer komponenter

Alle komponenter er ikke ens. Progressive web components findes i tre smagsretninger:

Composite-komponenter bygger på eksisterende HTML. Et dropdown baseret på <select> eller tabs via lister. Light DOM sikrer accessibility og framework-kompatibilitet.

Primitive komponenter er selvstændige. Date picker, slider eller kalender viser HTML først. JS tilføjer senere interaktion.

Declarative Shadow DOM-komponenter bruger native Shadow DOM med SSR-støtte. Ideelt til stærk style-isolering uden server-krångel.

Vælg det, der passer. Ingen stive regler – kun lagdeling.

Udfordringer i praksis

Filosofien er fin. Men at bygge den konsekvent på dusinvis af komponenter kræver håndværk.

Et rigtigt progressivt bibliotek skal mestre:

• Prop- og attribute-synk på tværs af frameworks
• Event delegation uden Shadow DOM
• Hydration uden unødvendig re-rendering
• CSS-scoping uden JS-overhead
• Accessibility fra bunden
• Server-side rendering uden speciel server-logik

De fleste biblioteker overlader det til dig. Resultat: Boilerplate og JS afhængighed, der ødelægger det progressive.

Ny arkitektur – nye prioriteter

En progressiv tilgang skifter fokus:

Send HTML først. Start med semantisk HTML, der virker med det samme. Styles med CSS. Gør det tilgængeligt. Tilføj JS sidst.

Gør JS valgfrit. Et formular med validering skal fungere uden JS. En menu skal være tilgængelig i basisform. Interaktion er bonus.

Brug platformen. Custom Elements, Shadow DOM (hvis nødvendigt), Slots og Declarative Shadow DOM er native. Byg med dem.

Støt alle frameworks. HTML-baserede komponenter kører i React, Vue, Angular, Svelte eller vanilla JS. Ingen adapters.

Render på serveren. HTML og CSS gør SSR simpelt. Basis fungerer uden tricks. Kompleks state hydreres client-side.

Hvor meget JS skal der med?

Spørg dig selv: Hvor meget JavaScript har et komponentbibliotek brug for?

Populære biblioteker vejer 50KB+. Progressive web components kan være meget lettere. Med HTML/CSS først og JS som enhancement? Kun 2,6KB overhead til hele frameworket.

Det betyder noget for performance. Mindre filer = hurtigere load, parsing og kørsel. På mobildata: 3 sekunder til interaktivitet i stedet for 8.

SSR uden besvær

SSR kræver normalt speciel server-kode. Progressive web components vender det om: HTML/CSS først gør dem SSR-klare fra starten.

Composite og declarative komponenter renderer direkte på serveren. Reaktive viser initial HTML, hydreres client-side.

Det fjerner et kæmpe hæmsko for web components i SSR-apper.

Biblioteker, der overlever

Ved designsystemer giver progressive web components noget sjældent: Ægte framework-uafhængighed.

Ingen React-bundlelås. Ingen Vue-binding. Komponenterne virker i dagens framework – og om tre år.

Det kræver disciplin. Hold dig fra JS-tung løsninger. Invester i semantisk HTML og smart CSS. Belønningen? Genbrugelige, hurtige og tilgængelige komponenter.

Konklusion

Web components fejler ikke. Vi har behandlet dem som JS-frameworks i stedet for HTML-elementer. Progressive web components bringer dem tilbage til rødderne: Start med webplatformen, tilføj lag klogt, og få noget let, fleksibelt og effektivt.

For teams med store designsystemer er det en stærk strategi.