Hva er WebAssembly? Nativ hastighet i nettleseren

01Hva er WebAssembly?

WebAssembly er et andre kjøreformat som nettlesere kan forstå ved siden av JavaScript. Det er standardisert av W3C og fungerer innebygd i alle store nettlesere som Chrome, Firefox, Safari og Edge. Brukeren trenger ikke installere noe.

Ikke la ordet «assembly» i navnet lure deg: Du skriver vanligvis ikke Wasm for hånd. Du skriver koden i et språk du er vant til og gjør den om til en .wasm-fil med en kompilator. Nettleseren laster raskt ned denne lille og kompakte filen, validerer den og kjører den ved å oversette den til maskinkode.

Det enkleste svaret på hva er wasm er kort sagt dette: et portabelt og trygt kompileringsmål som flytter ytelsen til skrivebordsapplikasjoner inn i nettleseren.

02Hvordan fungerer WebAssembly?

JavaScript kommer som tekst. Nettleseren tolker den, kjører den og optimaliserer den underveis. WebAssembly kommer derimot ferdig kompilert. Siden typene er kjent og strukturen er streng, kan nettleseren kjøre det med langt færre antakelser og med forutsigbar hastighet.

1. Utvikleren skriver koden i et språk som C++, Rust, Go eller C#.
2. Kompilatorens verktøykjede gjør koden om til en .wasm-modul.
3. Nettsiden laster og starter modulen via JavaScript.
4. JavaScript kaller Wasm-funksjonene og viser resultatene i grensesnittet.

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('/hesap.wasm')
);

console.log(instance.exports.topla(2, 3)); // 5

03Forskjellen på Wasm og JavaScript

Forskjellen på Wasm og JavaScript blir ofte misforstått. WebAssembly er laget for å hjelpe der JavaScript sliter, ikke for å drepe det. Grensesnitt, hendelseshåndtering og interaksjon på siden er fortsatt JavaScripts oppgave.

Den virkelige gevinsten med Wasm ser man i tung databehandling. Men det er ikke raskere for alle oppgaver: Hyppig flytting av data mellom JavaScript og Wasm gir ekstra kostnader. Ved små oppgaver kan denne kostnaden spise opp gevinsten.

04Bruksområder for WebAssembly

Bruksområdene for WebAssembly vokser for hvert år. Fellesnevneren er at oppgaver som tidligere var umulige eller svært trege i nettleseren, nå kan gjøres uten installasjon.

Design- og medieverktøy

Profesjonelle designapplikasjoner, bilderedigeringsprogrammer og videokonverterere som kjører i nettleseren, bruker Wasm til de tunge prosesseringskjernene. Du kan for eksempel komprimere en video direkte i nettleseren uten å laste den opp til en server.

Spill, 3D og simulering

Spillmotorer kan kompilere utdataene sine til Wasm. Sammen med det nye grafikkgrensesnittet vi forklarer i artikkelen hva er WebGPU, kan man bygge opplevelser som ligner på konsoller i nettleseren.

Forretningsapplikasjoner og data

Databaser som kjører i nettleseren, PDF-behandling, kryptering, CAD-visere og avanserte beregningsmotorer drar nytte av Wasm. Eksisterende skrivebordskode kan flyttes til nettet uten å skrives om, noe som betyr at bibliotekene man har utviklet i årevis kan beholdes.

Bruk utenfor nettleseren

Takket være grensesnittet WASI kan Wasm også kjøre på server, i kantberegning og i utvidelsessystemer. Den lette og isolerte strukturen gjør det til et attraktivt valg for å kjøre utvidelser på en trygg måte.

05Hvilke språk kan man skrive Wasm i?

Det finnes mange språk som kan kompileres til Wasm, men de er ulikt modne. De vanligste valgene er C/C++ og Rust. Rust utmerker seg på dette feltet med minnesikkerhet og verktøystøtte. Du finner mer i artikkelen hva er Rust.

• C og C++: Moden og utbredt støtte med verktøykjeden Emscripten.
• Rust: En god bro til JavaScript med wasm-pack og wasm-bindgen.
• Go: Wasm-utdata med den offisielle kompilatoren. Utdataene er relativt store.
• C# / .NET: .NET-applikasjoner i nettleseren med Blazor.
• AssemblyScript: For dem som vil skrive Wasm med syntaks som ligner på TypeScript.

cargo install wasm-pack
wasm-pack build --target web

06Ytelse: hvor ligger den reelle gevinsten?

Å legge Wasm til på en nettside gjør ikke siden raskere av seg selv. På en bedriftsnettside eller i en butikk som kjører på en nettbutikkplattform er de egentlige årsakene til treghet som oftest store bilder, unødvendige skript og serverens svartid. Disse problemene løses med arbeid med hastighet og ytelse, ikke med Wasm.

Der Wasm virkelig skinner, er applikasjoner som krever høy ytelse i nettleseren: beregninger med millioner av operasjoner i sekundet, bildefiltre, komprimering og simulering. Her kan gevinsten være stor, men det er galt å bestemme seg uten å måle.

07Grenser og ting å passe på

WebAssembly er et kraftig verktøy, men passer ikke for alle prosjekter. Teamets kompetanse, hvor lett det er å feilsøke og vedlikeholdskostnadene bør også inngå i beslutningen.

• Feilsøking er mer arbeidskrevende enn i JavaScript. Kildekart er ikke alltid perfekte.
• Å flytte store datamengder mellom JavaScript og Wasm kan svekke ytelsen.
• Modulstørrelsen kan vokse avhengig av språket og bibliotekene som brukes.
• Teamet må ha utviklere som behersker språkene som kompileres.
• Kompilerte moduler må også testes. Tilnærmingene i artikkelen hva er programvaretesting gjelder også her.

08Før du tar Wasm i bruk i prosjektet

Før du bestemmer deg for WebAssembly, må du definere problemet riktig. Ofte kommer følelsen av treghet ikke fra beregninger, men fra nettverksforespørsler, store pakker eller unødvendige gjentegninger. Da øker Wasm bare kompleksiteten uten å løse problemet.

Den riktige tilnærmingen er å finne flaskehalsen først med nettleserens ytelsesverktøy, og deretter flytte bare den delen til Wasm. Resten av applikasjonen kan forbli JavaScript eller TypeScript, slik at teamet fortsetter å jobbe med verktøyene det er vant til.

1. Finn flaskehalsen ved å måle med profileringsverktøy.
2. Hold inn- og utdata for delen som flyttes små og tydelige.
3. Ta vare på JavaScript-versjonen av samme jobb for sammenligning.
4. Hent modulen bare når den trengs, med lazy loading.
5. Test på eldre enheter og mobil under reelle brukerforhold.

09Fremtiden for WebAssembly

Standarden modnes hvert år med tillegg som tråder (threads), SIMD-instruksjoner og støtte for søppelinnsamling. Støtten for søppelinnsamling har åpnet veien for at språk som Java, Kotlin og Dart også kan kompileres mer effektivt til Wasm.

I nær fremtid vil grensen mellom webapplikasjoner og skrivebordsapplikasjoner bli enda tynnere. For bedrifter betyr det at kraftige forretningsapplikasjoner uten installasjon blir mulig. Grensesnittet til en slik applikasjon er minst like viktig som motoren, og her er det UI/UX-design som avgjør brukeropplevelsen.