I to tiår har vi bare hatt et programmeringsspråk tilgjengelig for bruk i en nettleser: JavaScript. Den langsomme døden til tredjeparts binære plugin-moduler har utelukket andre språk, som Java og Flashs ActionScript, som førsteklasses borgere for nettutvikling. Andre webspråk, som CoffeeScript, er bare samlet til JavaScript.
Men nå har vi en ny mulighet: WebAssembly, eller WASM for kort. WebAssembly er et lite, raskt binært format som lover nesten naturlig ytelse for webapplikasjoner. I tillegg er WebAssembly designet for å være et samlingsmål for alle språk, JavaScript er bare ett av dem. Med hver eneste store nettleser som nå støtter WebAssembly, er det på tide å begynne å tenke på alvor om å skrive apps på klientsiden for nettet som kan kompileres som WebAssembly.
Det er verdt å merke seg at WebAssembly-apper ikke er ment å være det erstatte JavaScript-apper - i det minste ikke ennå. Tenk i stedet på WebAssembly som en kompanjong til JavaScript. Der JavaScript er fleksibelt, dynamisk skrevet og levert gjennom menneskelig lesbar kildekode, er WebAssembly høyhastighets, sterkt skrevet og levert via et kompakt binært format.
Utviklere bør vurdere WebAssembly for ytelseskrevende brukstilfeller som spill, musikkstreaming, videoredigering og CAD-applikasjoner.
Hvordan fungerer WebAssembly
WebAssembly, utviklet av W3C, er med ordene til skaperne et "kompileringsmål". Utviklere skriver ikke WebAssembly direkte; de skriver på språket de ønsker, som deretter blir samlet til WebAssembly bytecode. Bytekoden kjøres deretter på klienten - vanligvis i en nettleser - der den blir oversatt til opprinnelig maskinkode og utført i høy hastighet.
WebAssembly-koden er ment å være raskere å laste inn, parsere og utføre enn JavaScript. Når WebAssembly brukes av en nettleser, er det fremdeles overhead for å laste ned WASM-modulen og sette den opp, men alt annet som er likt, går WebAssembly raskere. WebAssembly gir også en sandboxed utførelsesmodell, basert på de samme sikkerhetsmodellene som eksisterer for JavaScript nå.
Akkurat nå er det vanligste å bruke WebAssembly i nettlesere, men WebAssembly er ment å være mer enn en nettbasert løsning. Etter hvert som WebAssembly-spesifikasjonen former seg og flere funksjoner lander i den, kan den bli nyttig i mobilapper, stasjonære apper, servere og andre kjøringsmiljøer.
WebAssembly brukstilfeller
Den mest grunnleggende brukssaken for WebAssembly er som et mål å skrive programvare i nettleseren. Komponentene som er samlet til WebAssembly kan skrives på et hvilket som helst antall språk; den endelige WebAssembly-nyttelasten leveres deretter via JavaScript til klienten.
WebAssembly er designet med tanke på en rekke ytelsesintensive, nettleserbaserte brukstilfeller: spill, musikkstreaming, videoredigering, CAD, kryptering og bildegjenkjenning, for å nevne noen få.
Mer generelt er det lærerikt å fokusere på disse tre områdene når du bestemmer nettstedet ditt for WebAssembly:
- Høy ytelseskode som allerede finnes på et målmålbart språk. For eksempel, hvis du allerede har en høyhastighets matematikkfunksjon skrevet i C, og du vil innlemme den i et webapplikasjon, kan du distribuere den som en WebAssembly-modul. De mindre ytelseskritiske, brukervendte delene av appen kan forbli i JavaScript.
- Høy ytelseskode som må skrives fra bunnen av, der JavaScript ikke er ideelt. Tidligere kunne man ha brukt asm.js til å skrive en slik kode. Du kan fortsatt gjøre det, men WebAssembly blir posisjonert som en bedre langsiktig løsning.
- Overføre et skrivebordsprogram til et webmiljø. Mange av teknologidemoene for asm.js og WebAssembly faller inn i denne kategorien. WebAssembly kan gi et substrat for apper som er mer ambisiøse enn bare en GUI presentert via HTML. (Se demonstrasjonene WebDSP, Zen Garden og Tanks.) Dette er imidlertid ikke en triviell øvelse, ettersom alle måtene skrivebordsprogrammet grensesnittet med brukeren må kartlegges til WebAssembly / HTML / JavaScript-ekvivalenter.
Hvis du har en eksisterende JavaScript-app som ikke skyver ytelseskonvolutter, er det best å være alene på dette stadiet av WebAssemblings utvikling. Men hvis du trenger den appen for å gå raskere, kan WebAssembly hjelpe.
WebAssemble språkstøtte
WebAssembly er ikke ment å bli skrevet direkte. Som navnet antyder, er det mer som et monteringsspråk, noe som maskinen bruker, enn et menneskelig vennlig programmeringsspråk på høyt nivå. WebAssembly er nærmere mellomrepresentasjonen (IR) generert av LLVM-språk-kompilatorinfrastrukturen, enn den er som C eller Java.
Dermed involverer de fleste scenarier for å jobbe med WebAssembly å skrive kode på et høyt nivå språk og gjøre det om til WebAssembly. Dette kan gjøres på en av tre grunnleggende måter:
- Direkte samling. Kilden oversettes til WebAssembly ved hjelp av språkets egen kompilatorverktøyskjede. Rust, C / C ++, Kotlin / Native og D har nå alle innfødte måter å sende ut WASM fra kompilatorer som støtter disse språkene.
- Tredjepartsverktøy. Språket har ikke innfødt WASM-støtte i verktøykjeden, men et tredjepartsverktøy kan brukes til å konvertere til WASM. Java, Lua og .Net-språkfamilien har støtte som dette.
- WebAssembly-basert tolk. Her er ikke selve språket oversatt til WebAssembly; i stedet kjører en tolk for språket, skrevet i WebAssembly, kode skrevet på språket. Dette er den mest tungvint tilnærmingen, siden tolken kan være flere megabyte kode, men det gjør at eksisterende kode skrevet på språket kan kjøre alt unntatt. Python og Ruby har begge tolker oversatt til WASM.
WebAssemble-funksjoner
WebAssembly er fortsatt i de tidlige stadiene. WebAssembly-verktøykjeden og implementeringen holder seg nærmere proof-of-concept enn produksjonsteknologi. Når det er sagt, har forvalterne av WebAssembly sikte på å gjøre WebAssembly mer nyttig gjennom en rekke tiltak:
Primitiver for søppeloppsamling
WebAss Assembly støtter ikke direkte språk som bruker minnesmodeller som samles inn søppel. Språk som Lua eller Python kan bare støttes ved å begrense funksjons sett eller ved å legge hele kjøretiden som en kjørbar WebAssembly-kjørbar. Men det pågår arbeid for å støtte søppelinnsamlede minnemodeller uavhengig av språk eller implementering.
Gjenging
Innfødt støtte for threading er vanlig for språk som Rust og C ++. Fraværet av trådstøtte i WebAssembly betyr at hele klasser av WebAssembly-målrettet programvare ikke kan skrives på disse språkene. Forslaget om å legge til threading til WebAssembly bruker C ++ threading-modellen som en av sine inspirasjoner.
Bulkhukommelsesoperasjoner og SIMD
Bulkhukommelsesoperasjoner og SIMD (single instruction, multiple data) parallelism er must-haves for applikasjoner som sliper gjennom hauger med data og trenger naturlig CPU-akselerasjon for å hindre kvelning, som maskinlæring eller vitenskapelige apper. Forslag ligger på bordet for å legge til disse funksjonene i WebAssembly via nye operatører.
Språkkonstruksjoner på høyt nivå
Mange andre funksjoner vurderes for WebAssembly kart direkte til høykonstruksjoner på andre språk.
- Unntak kan emuleres i WebAssembly, men kan ikke implementeres naturlig via WebAssemblings instruksjonssett. Den foreslåtte planen for unntak innebærer unntaksprimitiver som er kompatible med C ++ - unntaksmodellen, som igjen kan brukes av andre språk som er samlet til WebAssembly.
- Referansetyper gjøre det lettere å passere rundt objekter som brukes som referanser til vertsmiljøet. Dette ville gjøre søppeloppsamling og en rekke andre funksjoner på høyt nivå enklere å implementere i WebAssembly.
- Hale samtaler, et designmønster som brukes på mange språk.
- Funksjoner som returnerer flere verdier, f.eks. via tupler i Python eller C #.
- Skilt-utvidelse operatører, en nyttig matematikkoperasjon på lavt nivå. (LLVM støtter også disse.)
Feilsøkings- og profileringsverktøy
Et av de største problemene med transpilert JavaScript var vanskeligheten med feilsøking og profilering på grunn av manglende evne til å korrelere mellom den transpilerte koden og kilden. Med WebAssembly har vi et lignende problem, og det blir adressert på en lignende måte (kildekartstøtte). Se prosjektets merknad om planlagt verktøystøtte.
