Nettet har siden starten hatt en utfordring som man har forsøkt å løse på flere måter: Hvordan distribuerer man en applikasjon til brukeren, slik at den kan kjøres like raskt som en lokal applikasjon?
Den siste satsingen på en teknologi som kan løse utfordringen er WebAssembly, som utvikles i et samarbeid mellom blant annet Mozilla, Google, Microsoft og Apple – og dermed er det lagt opp til støtte i alle de mest brukte nettleserne.
Men dette er ikke så enkelt, og ifølge den danske dataeksperten Anders Hejlsberg, som i årevis har jobbet med utvikling av programmeringsspråk, vil WebAssembly sannsynligvis bare være relevant for noen nisjer.
– Hvis du utvikler spill eller skal lage en «compute engine», kan det kanskje brukes. Men hvis du ellers skriver «native» kode, er du vel interessert i best mulig ytelse? Det får du fremdeles ikke i WebAssembly, mener Anders Hejlsberg.
Native kode er for eksempel programmer skrevet i C, som så oversettes til et binært format som kan kjøres direkte på maskinvaren. Programmet oversettes til den konkrete arkitekturen, og det gir muligheter til å foreta noen optimeringer som er vriene å gjøre hvis man skriver en applikasjon i for eksempel JavaScrip,t som kjører i en sandkasse i nettleseren, og oversettes mens applikasjonen kjører.
Java-appletter og ActiveX
Denne utfordringen har også vært forsøkt løst tidligere. Java-appletter var en metode for å gi mulighet for å distribuere oversatt bytekode fra Java via nettleseren til en spesiell sandkasse. ActiveX og Flash kan også sees på som forsøk på det samme.
WebAssembly er i seg selv en videreutvikling av blant annet ASM.js og Emscripten. Med disse kan man oversette kode fra C eller C++ til JavaScript, men WebAssembly har til hensikt å gå et skritt videre.
Målet med WebAssembly er ifølge et dokument fra de fire nettleser-produsentene å danne en abstraksjon fra maskinvaren, men som fremdeles gjør det mulig via nettet å bruke et lavnivåspråk med bytecode som kan avvikles effektivt med svært lite overhead, og som er plattformuavhengig.
Men dette er ikke enkelt når det skal være både sikkert – slik at det kan distribueres via nettet – og effektivt og plattformuavhengig. Med lavnivåspråk har man vanligvis adgang til å manipulere registre i minnet, men dette vil være for usikkert via nettet, siden det potensielt vil kunne utnyttes til å kompromittere styringssystemet.
Derfor jobber WebAssembly i stedet med en stor matrise («array») som representerer minnet. Det gjør på sett og vis også ASM.js, men her er matrisen bare en stor JavaScript-matrise.
– Problemet er at det tar tid å «parse» JavaScript. Med WebAssembly får man dermed bytecode, men det kjører fremdeles i en sandkasse i en nettleser med et array som minne, sier Anders Hejlsberg.
For å gi WebAssembly tilstrekkelig med sikkerhet, er minnematrisen atskilt fra selve programkoden, slik at en WebAssembly-applikasjon bare kan manipulere den tildelte matrisen, og ikke selve programmet eller miljøet omkring det.
Lavnivå-kontroll
WebAssembly vil være egnet til applikasjoner der JavaScript ville være upraktisk, eller der utvikleren har behov for den spesielle kontrollen som et lavnivå-språk kan gi. En av fordelene er at en WebAssembly-applikasjon bygges opp i moduler i binær kode. Hver modul er bygget opp slik at det er mulig å starte med avviklingen av applikasjonen mens data blir streamet til klienten.
Men en WebAssembly-applikasjon står ikke helt alene, men skal kalles opp via JavaScript, samtidig som det også er mulig å kompilere koden via JavaScript.
For å være så plattformuavhengig som mulig, er WebAssembly også et svært enkelt lavnivå-språk med for eksempel bare fire value-typer, og det er ingen innebygd objektmodell. Fordelen er at det vil være mulig å bruke ganske mange ulike programmeringsspråk som utgangspunkt, og deretter oversette dem til det binære formatet i WebAssembly.
For tiden er WebAssembly kommet til det stadiet der nettleserprodusentene tester implementeringen, og det finnes støtte for C og C++. Planen er at flere høynivå-språk skal kunne oversettes så de kan kjøre på WebAssembly, og samtidig kan det for eksempel være behov for å gi applikasjoner mulighet for å utnytte nettleserens opprenskning av datalageret, noe som kan være nyttig hvis man optimerer kode.
