Svelte eller React?

React er standardvalget til at bygge moderne webbrugerflader, og for de fleste projekter er det det rigtige valg uden videre diskussion. Svelte er udfordreren der gør visse ting smartere og slankere. Det interessante spørgsmål er derfor ikke “hvad er bedst” i almindelighed, men: Hvornår er det klogt at afvige fra standardvalget? Her er afvejningen.

Sveltes kompileringsmodel og performance

Den tekniske forskel kan forklares uden dyb teknik. React sender et bibliotek, et stykke frameworkkode, med ud i brugerens browser, hvor det klarer en del af arbejdet. Det fungerer fremragende, men det betyder at hver besøgende downloader frameworket oven i din faktiske app.

Svelte vender det om. I stedet for at sende frameworket med udfører Svelte det meste af arbejdet på forhånd når koden bygges, og kompilerer frameworket helt væk. Det der når brugeren, er så mindre og mere strømlinet kode. Det svarer nogenlunde til forskellen på at få et møbel som samlesæt med værktøj og at få det færdigsamlet.

Effekten er konkret: mindre at downloade og ofte en hurtigere fornemmelse, især på svage mobiler og dårlige forbindelser hvor hver kilobyte kan mærkes. For et produkt hvor hastighed og størrelse er selve pointen (en widget der skal indlejres på andres sider, en tjeneste til simple enheder), kan det være en reel fordel. Samtidig skal det siges ærligt: For mange almindelige tjenester er React allerede hurtigt nok, og de sidste kilobytes afgør sjældent noget.

Risikoen: økosystem og talentpulje

Performance er kun den ene side. Den anden, og ofte vigtigere, er hvad der sker når produktet skal bygges færdigt og derefter driftes og vedligeholdes i årevis.

Her har React en massiv fordel. Økosystemet er enormt: Til næsten ethvert behov (kalendere, tabeller, grafer, betalingsflows) findes der allerede færdige, testede komponenter at bygge videre på. Med Svelte er udbuddet mindre, hvilket betyder at I oftere må bygge ting selv. Det koster tid og penge, og det I selv bygger, bliver også jeres at vedligeholde.

Mindst lige så vigtig er talentpuljen. React-udviklere er en stor og let tilgængelig gruppe; Svelte-udviklere er markant færre. For et produkt der skal leve længe, er det en reel risiko: Kan I hurtigt finde en afløser når nogen stopper, eller hente flere ind når teamet skal vokse? Med React er svaret næsten altid ja. Med Svelte kan det blive en flaskehals der først mærkes når det er ubelejligt.

Beslutningsregel

Afvejningen kan koges ned til en enkel regel.

Vælg Svelte når performance er en afgørende produktegenskab og projektet er tilstrækkeligt afgrænset til at det mindre økosystem ikke bliver en hindring. Vælg React når vedligeholdelse over flere år, adgang til udviklere og et modent økosystem vejer tungest, hvilket det gør for de fleste brede systemer.

Et konkret eksempel: Skal I bygge en let, indlejrbar prisberegner der skal indlæses hurtigt på tusindvis af eksterne sider, kan Svelte være helt rigtigt. Skal I bygge en forretningskritisk platform der skal vokse, driftes og vedligeholdes i årevis, er React det trygge valg, og at vælge standarden er sjældent noget I behøver at forsvare.

Flere kriterier at tage med i betragtning

Størrelse og økosystem er de tunge spørgsmål, men beslutningen bliver tryggere hvis du også tjekker et par praktiske punkter:

• Hvem skal vedligeholde koden om et år? Et internt team der allerede kan React, har en lettere vej frem end et der skal lære noget nyt ved siden af. Skal en ekstern part overtage senere, vejer den bredere talentpulje endnu tungere.
• Hvor længe skal produktet leve? En kampagneside der lever et kvartal, kan tåle et mere dristigt valg end en platform der skal bære forretningen i fem år. Jo længere horisont, desto mere værd er et trygt og velbemandet fundament.
• Hvor meget færdigt har I brug for? Skal løsningen læne sig op ad mange færdige byggeklodser (tabeller, grafer, betalingsflows), er Reacts store udbud en konkret tidsbesparelse. Bygger I alligevel det meste specifikt, betyder udbuddet mindre.
• Hvor central er performance? Skeln mellem “vil gerne have det hurtigt” og “falder uden hastighed”. Først når hastighed og størrelse er selve produktegenskaben, begynder Sveltes fordel at veje tungere end risikoen.

En almindelig fejl

Den mest almindelige fejl er at vælge Svelte til en bred platform med lang levetid alene fordi det sender mindre kode, i et projekt hvor performance aldrig var det egentlige problem. Et år senere stopper den der kendte teknikken bedst, en afløser skal ind, og den lille talentpulje bliver et dyrt problem mens de sparede kilobytes aldrig gjorde en målbar forskel for brugerne. Fejlen er ikke at kunne lide Svelte, men at lade en teknisk finesse afgøre en beslutning der i virkeligheden handler om bemanding, drift og vedligeholdelse i årevis.

Det er også værd at skelne dette spørgsmål fra et par andre som det blandes sammen med. Er det egentlige behov måske en enklere, indholdsdrevet side helt uden et tungt framework, er det mere grundlæggende at få afklaret først. Og hvordan siden skal renderes og driftes (i browseren, på serveren eller forhåndsbygget), er et separat vejvalg uanset om fundamentet bliver Svelte eller React.

Hvorfor “bedst i test” sjældent afgør

Det er let at blive hængende i sammenligningstabeller hvor Svelte vinder på størrelse og hastighed, og konkludere at det derfor er det bedre valg. Men et framework lever ikke i et testlaboratorium. Det skal bygges i, rekrutteres til og vedligeholdes i årevis. De egenskaber vejer næsten altid tungere end nogle få kilobytes forskel i en måling.

Det er derfor standardvalget findes. At vælge det etablerede er ikke fantasiløshed, men en måde at sænke risikoen på: Du ved at der er folk at hyre, løsninger at genbruge og en lang fremtid for teknologien. Et teknisk overlegent værktøj som I får svært ved at bemande, kan blive en dyrere affære end et lidt tungere værktøj som halvdelen af markedet kan.

At veje teknologivalg op mod forretning, drift og vedligeholdelse er præcis den slags beslutninger vi hjælper med i vores ydelser. Vil du have afklaret om dit projekt hører til undtagelserne hvor det betaler sig at afvige? Kontakt os, så kigger vi på det sammen.