<ForrigeUke uke="46" år="2025" />
Optimistisk UI med remote functions i Svelte, Vercels forsvar mot anklager om vendor lock-in, og finjustering av nettsideytelse med DNS-prefetching — alt dette i denne ukas ForrigeUke.
Dette var uka for hundeheiser 🛗, close calls 🤏🏻 – og 1390 ting skjedde i frontend-verdenen.
«<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uken som var.»
Fjernkontroll i Svelte 📺
Selv om det nå begynner å bli godt over en måned siden ViteConf 2025 gikk av stabelen, fortsetter konferansen å gi. For forrige uke kom nemlig foredraget til Rich Harris, forfatteren bak Svelte og Rollup, ut på teip! Der viser Rich frem Sveltes nye remote functions. For oss som ikke nødvendigvis ferdes i Svelte-land daglig kan Svelte remote functions kanskje best sammenlignes med en slags sammenslåing av Reacts serverkomponenter og serverfunksjoner. For remote functions i Svelte lar deg ikke bare kalle på funksjoner i serveren, men også koble deg på tilstand som lever der.
Men, hvis appen din skal basere seg utelukkende på funksjonskall og tilstand på serveren så vil jo fort tjenesten din oppleves treg og uresponsiv. Heldigvis kommer remote functions med støtte for optimistisk UI, som gjør det mulig å late som om at alt gikk bra og oppdatere visningen for brukeren mens vi venter på at serveren skal prosessere funksjonskallene våre.
Jeg må si at dette så helt magisk lett ut! Jeg har alltid vært forelsket i hvor enkelt React Server Components-paradigmet gjør livet mitt, men sånn som Rich viser frem Sveltes remote functions må jeg si at jeg kan ikke fatte hvor vanskelig React Server Components egentlig er. Dette er jo så mye lettere!
Rich Harris | Remote Control | ViteConf 2025
Rich Harris, creator of Svelte and Rollup, presents an exploration of reactive systems and the benefits of using fine-grained reactivity ...
Driver Vercel med vendor lock-in? 🔒
En av de største kritikkene jeg hører om Next.js og Vercel er at de driver med vendor lock-in. Årsaken til dette er at det å gjenskape det du får ved å hoste tjenester hos Vercel er såpass vanskelig. Et eksempel på dette er at en Next.js app på Vercel lager en egen serverless-funksjon per side i applikasjonen din, men skal du gjenskape det samme på egen infrastruktur så må du ty til open-source biblioteker som OpenNext. Next.js teamet har rett og slett ikke investert i at du skal kunne gjenskape det samme kjøretidsmiljøet på andre plattformer.
Vercel har kanskje blitt litt lei av denne kritikken, fordi forrige uke kom de ut med en bloggpost de har gitt tittelen, Vercel: The anti-vendor-lock-in cloud. Her beskriver de hvordan utviklere skal slippe å forholde seg til tjeneste-spesifikke primitiver; Vercel tolker istedet bygget og oppretter dem automatisk. Siden utvikleren ikke trenger å forholde seg til tjeneste-spesifikke primitiver direkte blir de altså anti-vendor-lock-in.
Jeg synes det de skriver gir mening. I de aller fleste tjenester jeg har hostet på Vercel har jeg nesten aldri måttet gjøre noe "Vercel"-spesifikt med koden min for at det skal fungere. Hva synes du om budskapet? Kjøper du det?
Vercel: The anti-vendor-lock-in cloud - Vercel
Framework-defined infrastructure interprets your code and provisions what you need, keeping your application portable across any platform.
Finjustering av ytelse 🤏
Når nettleseren skal hente en ekstern ressurs – som et bilde, CSS eller JavaScript – må den først slå opp domenet via DNS, deretter etablere en TCP-tilkobling og så sette opp en kryptert HTTPS-forbindelse gjennom en SSL/TLS-handshake. Når alt dette er på plass kan endelig nettleseren faktisk begynne med det vi egentlig skulle gjøre: å laste ned selve ressursen.
Nettleseren din er ganske god på å optimalisere innlasting av de initielle ressursene, så dette er ofte ikke noe du trenger å tenke så mye på. Men, for ressurser som lastes inn dynamisk i etterkant, vil det fort bli vanskelig for nettleseren din å hjelpe deg. Så her må vi inn og gi noen hint til nettleseren din hvis vi ønsker å gi brukeren en kjapp brukeropplevelse. Men, hvordan gjør vi det?
Et typisk, og godt, steg for optimalisering er at du forhåndslaster hele ressursen før du trenger den. Dette gjør at når den så blir etterspurt, trenger ikke brukeren vente på å laste den inn i det hele tatt. Dette er ypperlig de gangene vi greier å forutsi hvilke ressurser en bruker kommer til å trenge (som for eksempel når en bruker holder musepekeren over en lenke). Men, for alle de ressursene vi ikke greier å forutsi om brukeren trenger blir ofte en sånn forhåndsinnlasting dyr.
Heldigvis har Alex MacArthur skrevet litt om en av de mindre kjente optimaliseringsstrategiene vi kan ta i bruk, nemlig forhåndslasting av DNS-oppslag. Selv om et så lite optimaliseringssteg som forhåndslasting av DNS-oppslag høres banalt ut, så utgjør det i sum kanskje mer enn du forventer. Og kanskje, som Alex skriver, kan du ende opp med fjeset ditt på fremtidens sedler!
«[...] when used in concert with the several other tools out there for tuning performance, you could end up with a bigger edge than you might've expected. The impact may just snowball from there, leading to mind-blowing conversion rates, great wealth, and global renown for your impact in the front-end website performance space. You could even convince the Secretary of the Treasury to put your face on a bill.– Alex MacArthur
Just dreamin' here.»
DNS Resolution Adds Up
DNS resolution is cheap, but it ain't free. In scenarios when it counts, the `dns-prefetch` resource hint could give you a nice, slight ...
