Bygg fremtidssikre designsystemer med progressive web components

Bygg fremtidssikre designsystemer med progressive web components

Mai 04, 2026 web-components design-systems progressive-enhancement javascript ssr accessibility web-standards

Bygg designsystemer som holder i morgen med progressive web components

Har du bygget store komponentbiblioteker for bedrifter? Da kjenner du spenningen. Web components gir ekte fleksibilitet – de fungerer overalt, uavhengig av rammeverk. Men de drar ofte med seg problemer: layout som hopper før JS laster, tilgjengelighetsutfordringer med Shadow DOM, og SSR som krever triks.

Vi har gjort det unødvendig komplisert.

Web components-paradokset

Slik går det ofte: Teamet velger web components for designsystemet. De lager Custom Elements, laster et tungt rammeverk, og plutselig sender de masse JS bare for en knapp. HTML kommer først, så JS overtar og tegner på nytt. Brukere ser blink av ustylt innhold. Skjermlesere sliter med Shadow DOM. SSR blir et mareritt.

Feilen ligger ikke i web components. Den ligger i hvordan vi bygger dem.

Tenk baklengs

De beste løsningene virker enkle i etterkant. Hva om komponentene starter med ren HTML og CSS? Hva om JS bare er et ekstra lag?

Det er kjernen i progressive web components – en tankegang, ikke et rammeverk. Komponentene har to lag:

Baselaget er HTML og CSS. Det vises med en gang, uten JS. Innhold er der, stil fungerer, siden er stabil.

Oppgraderingslaget er JS for interaksjon, events og reaktivitet – kun når det trengs.

Tre typer komponenter

Alle komponenter trenger ikke samme oppsett. Progressive web components finnes i tre smaker:

Kompositt-komponenter bygger på eksisterende HTML. En dropdown bruker <select>, en tab bruker lister. Light DOM sørger for tilgjengelighet og kompatibilitet med alle rammeverk.

Primitive komponenter er selvstendige. Datepicker, slider eller kalender viser HTML først. JS legger til interaksjon etterpå.

Deklarative Shadow DOM-komponenter bruker innebygd Shadow DOM, men støtter SSR. Ideelt for sterk stilisolering uten serverproblemer.

Du velger det som passer. Ingen stiv regler – bare lagdeling.

Utfordringen med å bygge det

Å forstå ideen er enkelt. Å lage det på tvers av mange komponenter er hardere. Et progressivt bibliotek må håndtere:

  • Synkronisering av props og attributter over rammeverk
  • Event-delegation uten Shadow DOM
  • Hydration uten unødvendig re-rendering
  • CSS-scoping uten JS-belastning
  • Tilgjengelighet fra bunnen av
  • SSR uten spesiallogikk

De fleste biblioteker lar deg løse dette selv. Du ender med boilerplate, og JS blir obligatorisk.

Nytt grunnlag for komponenter

Et progressivt design endrer prioriteringene:

Send HTML først. Start med semantisk HTML som fungerer alene. Stil med CSS. Gjør det tilgjengelig. Legg JS på toppen for interaksjon.

Gjør JS valgfritt. Et skjema med validering skal virke uten JS. En meny skal være navigérbar i ren HTML. Oppgraderinger føles som bonus.

Bruk plattformen. Custom Elements, Shadow DOM (når det passer), Slots og Declarative Shadow DOM er browser-funksjoner. Bygg med dem.

Støtt alle rammeverk. HTML-basen fungerer i React, Vue, Angular, Svelte eller vanilla JS. Ingen adaptere.

SSR som standard. HTML og CSS rendres på serveren uten problemer. Kompleks state hydreres på klientsiden.

Hvor stor skal biblioteket være?

Hvor mye JS trenger et komponentbibliotek? Populære løsninger veier 50 KB+. Progressive web components kan være mye mindre. Med HTML/CSS først og JS som ekstra, kan hele rammeverket være 2,6 KB. Resten er komponentene dine.

Det teller i praksis. Mindre størrelse gir raskere nedlasting, parsing og kjøring. På mobilnettverk: 3 sekunder til interaksjon, ikke 8.

SSR uten mas

SSR krever vanligvis spesiell serverlogikk. Progressive web components snur det: HTML/CSS først betyr SSR som standard.

Kompositt- og deklarative komponenter rendres direkte på serveren. Reaktive komponenter viser initial HTML, så hydreres de på klienten.

Det fjerner en stor brems for web components i SSR-apper.

Designsystemer som varer

Ved å bygge designsystemer med progressive web components får du noe sjeldent: frihet fra rammeverk uten kompromiss.

Ingen React-bundle-lås. Ingen Vue-avhengighet. Komponentene funker med dagens verktøy – og morgendagens.

Det krever disiplin. Dropp JS-løsninger på alt. Fokuser på semantisk HTML. Tenk CSS grundig. Men gevinsten er gjenbrukbare, raske og tilgjengelige komponenter.

Konklusjonen

Web components svikter ikke. Vi har behandlet dem som JS-rammeverk, mens de egentlig er HTML-elementer. Progressive web components går tilbake til basics: start med webplattformen, legg lag klokt, og få noe lite, fleksibelt og raskt.

For team som bygger store designsystemer er det en smart vei å gå.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NL HU IT FR ES DE DA ZH-HANS EN