Svelte eller React: ytelsestesten peker én vei, migreringen en annen

For en ny webapplikasjon uten bindinger til React er Svelte et godt valg når raske oppdateringer av grensesnittet er viktig. Har dere allerede en fungerende React-løsning, er en migrering vanskeligere å begrunne med renderytelse alene. Den publiserte testen viser en stor forskjell i et bestemt komponenttre, mens en flytting også krever arbeid med kode, integrasjoner og kompetanse.

Valget avhenger dermed av hvilket problem teamet har. Ved nyutvikling kan dere velge arkitektur ut fra kravene som ligger foran dere. I en eksisterende applikasjon må en mulig gevinst veies mot det som allerede fungerer, og React Compiler gir et alternativ for å redusere unødvendig rendring innenfor React.

Hvorfor Sveltes modell kan gi raskere oppdateringer

Svelte flytter arbeid fra kjøring i nettleseren til byggetrinnet. Sveltes dokumentasjon for kompilatoren beskriver hvordan komponentkilde blir en JavaScript-modul, med kode som kan genereres for klient eller server. Kompilatoren kan dermed behandle komponentens struktur før applikasjonen kjøres.

Ved en liten endring i et stort grensesnitt er det relevant hvor mye av komponenttreet som må behandles på nytt. I den testede Svelte-modellen kunne oppdateringen avgrenses til berørte komponenter og databindinger. Dersom mye av innholdet er statisk, kan det gi mindre renderarbeid enn en strategi som også behandler uendrede deler av treet.

Denne forskjellen gjelder en del av applikasjonens arbeid. En bruker kan fortsatt vente på nettverk, databehandling, bilder eller nettleserens layout. Derfor er en rask komponentoppdatering et argument for Svelte særlig når rendring faktisk er en viktig del av forsinkelsen brukeren merker.

Hva rendertesten målte

I studien publisert i Journal of Web Engineering i 2022 tok en full renderingssyklus 439 ms med React 17.0.1 og 24 ms med Svelte 3.35.0 da rotkomponenten i et binært tre med 32 768 komponenter ble oppdatert. Tallet gjelder en oppdatering av et eksisterende tre, ikke opprettelsen av hele treet første gang.

En endring ved roten er et krevende tilfelle for en strategi som behandler mange underkomponenter på nytt. Når en bladkomponent ble oppdatert i samme testoppsett, var arbeidet langt mer avgrenset også for React. Forskjellen mellom slike situasjoner er vesentlig: Plasseringen av endringen i treet påvirker hvor mye rendring rammeverket må gjøre.

Målingen av den fulle syklusen omfatter både skriptkjøring og nettleserens videre renderarbeid. Komponentene var samtidig bevisst enkle, uten egen styling og med få attributter. Resultatet viser derfor en forskjell mellom renderstrategier under disse betingelsene; det gir ingen forventet tidsbesparelse for en ferdig tjeneste med datatilgang, navigasjon og mer sammensatte komponenter.

Versjonene er også viktige for beslutningen. React Compiler inngikk ikke i forsøket, og den målte React-løsningen kan ikke behandles som en måling av React med denne optimaliseringen. Testen er mest nyttig som forklaring på hvorfor oppdateringer høyt i store komponenttrær kan bli kostbare.

Hva React Compiler endrer

React Compiler angriper en del av det samme renderarbeidet uten at komponentene må flyttes til Svelte. Reacts forklaring av React Compiler beskriver automatisk memoisering under bygging, særlig for oppdateringer av eksisterende komponenter. Kompilatoren kan gjenbruke resultater og hindre at underkomponenter rendres på nytt når relevante verdier er uendret.

For et React-team betyr det at den eldre tidsforskjellen ikke kan oversettes direkte til en forventet gevinst ved migrering. Kompilatoren endrer hvor mye arbeid React gjør i enkelte oppdateringer, men effekten avhenger av koden og av hva som utløser rendring. Den løser heller ikke en treg nettverksforespørsel eller kostbar layout i nettleseren.

Det er dessuten forskjell på å forbedre rendring og å forbedre hele brukerhandlingen. Hvis en treg visning hovedsakelig venter på data, kan mindre omrendring gi liten synlig effekt. Hvis mange uendrede underkomponenter derimot rendres ved hver handling, er det nettopp en type arbeid Compiler er laget for å redusere. Den forskjellen må inngå i sammenligningen før et rammeverksbytte får en forventet verdi.

Hva en migrering faktisk koster

En etablert React-applikasjon består av mer enn komponentenes renderstrategi. Egne hooks, tilstandshåndtering, ruting, skjemaer, tester og interne komponentbiblioteker kan være knyttet til måten React-koden er bygget på. Å flytte løsningen innebærer å erstatte eller tilpasse slike deler og samtidig bevare oppførselen brukerne er avhengige av.

Omfanget varierer med kodebasen. Et lite, avgrenset grensesnitt kan være lettere å flytte enn en løsning med delte komponenter og mange integrasjoner. Under en overgang kan teamet også måtte vedlikeholde gammel og ny kode parallelt. Ingen av disse kostnadene kan leses ut av en syntetisk måling av et komponenttre.

React Compiler kan prøves mer avgrenset. Reacts veiledning for gradvis innføring beskriver bruk i utvalgte deler av en kodebase, med kontroll av oppførsel og måling av ytelse før utrullingen utvides. Det gjør en mulig rendergevinst lettere å undersøke innenfor den eksisterende løsningen.

Kompetanse påvirker også regnestykket. Et team som kjenner React-koden, integrasjonene og feilbildene godt, kan ha lavere risiko ved å forbedre den enn ved å innføre et nytt rammeverk. For et nytt produkt er denne bindingen svakere, men bibliotekene prosjektet trenger og teamets mulighet til å vedlikeholde løsningen er fortsatt konkrete deler av valget.

Valget for ny kode og eksisterende React

Ved nyutvikling peker Svelte sterkest mot prosjekter med få React-bindinger og grensesnitt der store eller hyppige oppdateringer kan bli en ytelsesutfordring. Den kompilerte modellen og den publiserte testen gir en teknisk begrunnelse for valget, mens nødvendige integrasjoner og tilgjengelig kompetanse avgjør om det også er et godt prosjektvalg. React kan være mer hensiktsmessig når eksisterende komponenter og erfaring gir teamet en tydelig fordel.

For en applikasjon som allerede kjører på React, begynner vurderingen med den trege brukerhandlingen: Hvor mye av forsinkelsen skyldes rendring, og hvor mye ligger andre steder? Dersom unødvendig omrendring er problemet, kan målrettede endringer eller React Compiler gi gevinst med mindre omlegging. En migrering blir mest relevant når et vedvarende problem fortsatt peker mot renderstrategien, og den forventede forbedringen er stor nok til å forsvare arbeidet med å flytte og vedlikeholde løsningen.

Les også:

• Microsoft 365 eller Google Workspace: migreringen kan spise lisenskuttet
• DaVinci Resolve eller Premiere Pro: én ytelsesscore kan villede
• TubeBuddy eller vidIQ: samme søkeord kan få 100 mot 34