Svelte eller React?

React er standardvalget for å bygge moderne webgrensesnitt, og for de fleste prosjekter er det riktig valg uten videre diskusjon. Svelte er utfordreren som gjør enkelte ting smartere og slankere. Det interessante spørsmålet er derfor ikke «hvilket er best» generelt, men: Når er det klokt å avvike fra standardvalget? Her er avveiingen.

Sveltes kompileringsmodell og ytelse

Den tekniske forskjellen lar seg forklare uten å gå dypt inn i teknikken. React tar med seg et bibliotek, en bit rammeverkskode, ut til nettleseren til brukeren, der det tar seg av en del av arbeidet. Det fungerer utmerket, men det betyr at hver besøkende laster ned rammeverket i tillegg til selve appen din.

Svelte snur det på hodet. I stedet for å sende med rammeverket gjør Svelte det meste av arbeidet på forhånd, når koden bygges, og kompilerer bort rammeverket helt. Det som kommer frem til brukeren, er da mindre og mer rendyrket kode, omtrent som forskjellen på et møbel du må skru sammen selv med verktøyet som følger med, og et møbel som leveres ferdig montert.

Effekten er konkret: mindre nedlasting og ofte en tjeneste som føles raskere, særlig på svake mobiler og dårlige forbindelser der hver kilobyte merkes. For et produkt der hastighet og størrelse er selve poenget, for eksempel en tjeneste for enkle enheter eller en widget som skal bygges inn på andres nettsider, kan det være en reell fordel. Samtidig skal det sies ærlig: For mange vanlige tjenester er React allerede raskt nok, og de siste kilobytene avgjør sjelden noe.

Risikoen: økosystem og rekrutteringsgrunnlag

Ytelse er bare den ene siden. Den andre, og ofte viktigere, er hva som skjer når produktet skal bygges ferdig og deretter forvaltes i årevis.

Her har React et massivt forsprang. Økosystemet er enormt: For nesten ethvert behov, som kalendere, tabeller, grafer og betalingsløsninger, finnes det allerede ferdige, testede komponenter å bygge videre på. Med Svelte er utvalget mindre, og det betyr at dere oftere må bygge ting selv. Det koster tid og penger, og det dere bygger selv, blir også deres å vedlikeholde.

Minst like viktig er rekrutteringsgrunnlaget. Flere utviklere jobber med React enn med Svelte, og det gjør det lettere å finne ansatte, konsulenter og byråer med riktig kompetanse. For et produkt som skal leve lenge, er forskjellen en reell risiko: Kan dere raskt finne en erstatter når noen slutter, eller hente inn flere når teamet skal vokse? Med React er svaret som regel ja. Med Svelte kan det bli en flaskehals som først merkes når det er ubeleilig.

Beslutningsregel

Avveiingen kan kokes ned til en enkel regel.

Velg Svelte når ytelse er en avgjørende produktegenskap og prosjektet er avgrenset nok til at det mindre økosystemet ikke blir et hinder. Velg React når forvaltning over tid, tilgang på utviklere og et modent økosystem veier tyngst, noe de gjør for de fleste brede systemer.

Et konkret eksempel: Skal dere lage en lett priskalkulator som skal bygges inn og laste raskt på tusenvis av eksterne nettsider, kan Svelte være helt riktig. Skal dere bygge en forretningskritisk plattform som skal vokse og forvaltes i årevis, er React det trygge valget, og å velge standarden er sjelden noe dere trenger å forsvare.

Flere kriterier å ta med i vurderingen

Størrelse og økosystem er de tunge spørsmålene, men beslutningen blir tryggere hvis du også sjekker noen praktiske punkter:

• Hvem skal forvalte koden om et år? Et internt team som allerede kjenner React, har en enklere vei videre enn et team som skal lære noe nytt ved siden av. Skal en ekstern part ta over senere, veier det bredere rekrutteringsgrunnlaget enda tyngre.
• Hvor lenge skal produktet leve? En kampanjeside som lever et kvartal, tåler et dristigere valg enn en plattform som skal bære virksomheten i fem år. Jo lengre horisont, desto mer verdt er et trygt fundament som er lett å bemanne.
• Hvor mye trenger dere å hente ferdig? Skal løsningen lene seg på mange ferdige byggeklosser, som tabeller, grafer og betalingsløsninger, er det store utvalget i React en konkret tidsbesparelse. Bygger dere uansett det meste skreddersydd, spiller utvalget mindre rolle.
• Hvor sentral er ytelsen? Skill mellom «vil gjerne ha det raskt» og «står og faller med hastigheten». Først når hastighet og størrelse er selve produktegenskapen, begynner fordelen med Svelte å veie tyngre enn risikoen.

En vanlig feil

Den vanligste feilen er å velge Svelte til en bred, langlivet plattform bare fordi det sender mindre kode, i et prosjekt der ytelse aldri var det egentlige problemet. Et år senere slutter den som kjente teknologien best, en erstatter skal inn, og det lille rekrutteringsgrunnlaget blir et dyrt problem, mens de sparte kilobytene aldri gjorde målbar forskjell for brukerne. Feilen er ikke å like Svelte, men å la en teknisk finesse avgjøre en beslutning som egentlig handler om bemanning og forvaltning i årevis.

Det er også verdt å skille dette spørsmålet fra et par andre spørsmål det ofte blandes sammen med. Er det egentlige behovet kanskje en enklere, innholdsdrevet side uten et tungt rammeverk i det hele tatt, er det mer grunnleggende å avklare det først. Og hvordan siden skal rendres og driftes, i nettleseren, på serveren eller ferdig bygd på forhånd, er et separat veivalg uansett om grunnlaget blir Svelte eller React.

Hvorfor «best i test» sjelden avgjør

Det er lett å stirre seg blind på sammenligningstabeller der Svelte vinner på størrelse og hastighet. Da trekker man fort den konklusjonen at Svelte er det bedre valget. Men et rammeverk lever ikke i et testlaboratorium. Det skal bygges i, rekrutteres til og vedlikeholdes i årevis. De egenskapene veier nesten alltid tyngre enn noen kilobytes forskjell i en måling.

Det er derfor standardvalget finnes. Å velge det etablerte er ikke fantasiløshet, men en måte å senke risikoen på: Du vet at det finnes folk å hente inn, løsninger å gjenbruke og en lang fremtid for teknologien. Et teknisk overlegent verktøy som dere sliter med å finne folk til, kan bli dyrere i lengden enn et litt tyngre verktøy som halve markedet kjenner.

Å veie teknologivalg opp mot forretning og forvaltning er nettopp den typen beslutninger vi hjelper til med i tjenestene våre. Vil du finne ut om prosjektet ditt hører til unntakene der det lønner seg å avvike? Ta kontakt, så ser vi på det sammen.