Sveltes remote function: – Ser magisk lett ut!

Sveltes nye remote functions imponerer React-bruker, Vercel vil bli kvitt ryktet sitt og finjustering av ytelse, i ukas ForrigeUke.

Vercel vil bli kvitt gamle rykter om å låse kundene inne.
Publisert

<forrigeUke />

ForrigeUke er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var. Innleggene skrives av frontend-faggruppene til Bekk, og kan også følges på bekk.no/fag.

Dette var uka for hundeheiser 🛗, close calls 🤏🏻 – og 1390 ting skjedde i frontend-verdenen.

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!

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?

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.

Eksempel fra artikkelen til Alex MacArthur som viser de forskjellige stegene i nettverksfanen i nettleseren. Lyseblå er DNS-oppslag, oransje er opprettelse av TCP-tilkoblingen, og lilla for å sette opp HTTPS-forbindelsen. De siste to, litt tjukkere, segmentene i grønn og blå er den faktiske innlastingen av ressursene.

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. Just dreamin' here.»

– Alex MacArthur

Powered by Labrador CMS