I to årtier har vi kun haft et programmeringssprog tilgængeligt til brug i en webbrowser: JavaScript. Den langsomme død af binære tredjeparts plug-ins har udelukket andre sprog, såsom Java og Flash's ActionScript, som førsteklasses borgere til webudvikling. Andre websprog, som f.eks. CoffeeScript, er kun udarbejdet til JavaScript.
Men nu har vi en ny mulighed: WebAssembly eller kort sagt WASM. WebAssembly er et lille, hurtigt binært format, der lover næsten oprindelig ydeevne til webapplikationer. Plus, WebAssembly er designet til at være et kompilationsmål for ethvert sprog, idet JavaScript kun er et af dem. Med hver større browser, der nu understøtter WebAssembly, er det tid til at begynde at tænke seriøst på at skrive apps på klientsiden til internettet, der kan kompileres som WebAssembly.
Det er værd at bemærke, at WebAssembly-apps ikke er beregnet til det erstatte JavaScript-apps - i det mindste endnu ikke. Tænk i stedet på WebAssembly som en ledsager til JavaScript. Hvor JavaScript er fleksibelt, indtastes dynamisk og leveres gennem menneskelig læsbar kildekode, er WebAssembly hurtig, stærkt skrevet og leveret via et kompakt binært format.
Udviklere bør overveje WebAssembly til præstationsintensive brugssager som spil, musikstreaming, videoredigering og CAD-applikationer.
Sådan fungerer WebAssembly
WebAssembly, udviklet af W3C, er med skabernes ord et "kompileringsmål". Udviklere skriver ikke WebAssembly direkte; de skriver på det sprog, de vælger, som derefter kompileres til WebAssembly bytecode. Bytecode køres derefter på klienten - typisk i en webbrowser - hvor den oversættes til indbygget maskinkode og udføres i høj hastighed.
WebAssemble-kode er beregnet til at være hurtigere at indlæse, parse og udføre end JavaScript. Når WebAssembly bruges af en webbrowser, er der stadig omkostningerne ved at downloade WASM-modulet og opsætte det, men alt andet lige er WebAssembly kører hurtigere. WebAssembly tilbyder også en eksekveringsmodel med sandkasse, der er baseret på de samme sikkerhedsmodeller, der findes for JavaScript nu.
Lige nu er kørsel af WebAssembly i webbrowsere den mest almindelige brugssag, men WebAssembly er beregnet til at være mere end en webbaseret løsning. Efterhånden som WebAssembly-specifikationen former sig, og flere funktioner lander i den, kan den blive nyttig i mobilapps, desktop-apps, servere og andre eksekveringsmiljøer.
WebAssemble brugssager
Den mest basale brugssag til WebAssembly er som et mål at skrive software i browseren. Komponenterne, der er kompileret til WebAssembly, kan skrives på et hvilket som helst af et antal sprog; den endelige WebAssembly-nyttelast leveres derefter via JavaScript til klienten.
WebAssembly er designet med et antal præstationsintensive, browserbaserede brugstilfælde i tankerne: spil, musikstreaming, videoredigering, CAD, kryptering og billedgenkendelse for blot at nævne nogle få.
Mere generelt er det lærerigt at fokusere på disse tre områder, når du bestemmer din særlige WebAssembly-brugssag:
- Højtydende kode, der allerede findes på et sprog, der kan målrettes mod. For eksempel, hvis du allerede har en højhastigheds matematikfunktion skrevet i C, og du vil inkorporere den i en webapplikation, kan du implementere den som et WebAssembly-modul. De mindre præstationskritiske, brugervenlige dele af appen kan forblive i JavaScript.
- Højtydende kode, der skal skrives fra bunden, hvor JavaScript ikke er ideelt. Tidligere kunne man have brugt asm.js til at skrive en sådan kode. Du kan stadig gøre det, men WebAssembly placeres som en bedre langsigtet løsning.
- Portering af en desktop-applikation til et webmiljø. Mange af teknologidemoerne for asm.js og WebAssembly falder inden for denne kategori. WebAssembly kan give et substrat til apps, der er mere ambitiøse end blot en GUI, der præsenteres via HTML. (Se demoserne WebDSP, Zen Garden og Tanks.) Dette er dog ikke en triviel øvelse, da alle måder, som desktop-applikationen grænseflader med brugeren, skal kortlægges til WebAssembly / HTML / JavaScript-ækvivalenter.
Hvis du har en eksisterende JavaScript-app, der ikke skubber til nogen ydeevenskonvolutter, er det bedst at være alene på dette stadium af WebAssemblings udvikling. Men hvis du har brug for den app til at gå hurtigere, kan WebAssembly måske hjælpe.
WebAssemble sprogstøtte
WebAssembly er ikke beregnet til at blive skrevet direkte. Som navnet antyder, er det mere som et samlingssprog, noget, som maskinen bruger, end et menneskeligt venligt programmeringssprog på højt niveau. WebAssembly er tættere på den mellemliggende repræsentation (IR), der genereres af LLVM-sprogkompilatorinfrastrukturen, end den er som C eller Java.
Således involverer de fleste scenarier for at arbejde med WebAssembly at skrive kode på et sprog på højt niveau og gøre det til WebAssembly. Dette kan gøres på en af tre grundlæggende måder:
- Direkte kompilering. Kilden oversættes til WebAssembly ved hjælp af sprogets egen kompilatorværktøjskæde. Rust, C / C ++, Kotlin / Native og D har nu alle indfødte måder at udsende WASM fra kompilatorer, der understøtter disse sprog.
- Tredjepartsværktøjer. Sproget har ikke oprindelig WASM-understøttelse i værktøjskæden, men et tredjepartsværktøj kan bruges til at konvertere til WASM. Java, Lua og .Net-sprogfamilien har alle en vis støtte som denne.
- WebAssemble-baseret tolk. Her oversættes selve sproget ikke til WebAssembly; snarere kører en tolk for sproget, skrevet i WebAssembly, kode skrevet på sproget. Dette er den mest besværlige tilgang, da tolken kan være adskillige megabyte kode, men det tillader, at eksisterende kode skrevet på sproget kører alt undtagen uændret. Python og Ruby har begge tolke oversat til WASM.
WebAssemble-funktioner
WebAssembly er stadig i de tidlige faser. WebAssembly-værktøjskæden og implementeringen forbliver tættere på proof-of-concept end produktionsteknologi. Når det er sagt, har WebAssemblings værger deres mål at gøre WebAssemblage mere nyttige gennem en række initiativer:
Primitiver til affaldssamling
WebAssembly understøtter ikke direkte sprog, der bruger hukommelsesmodeller, der er indsamlet skrald. Sprog som Lua eller Python kan kun understøttes ved at begrænse funktionssæt eller ved at indlejre hele køretiden som en eksekverbar WebAssembly. Men der er arbejde i gang med at understøtte skraldopsamlede hukommelsesmodeller uanset sprog eller implementering.
Trådning
Native support til threading er fælles for sprog som Rust og C ++. Fraværet af trådningsstøtte i WebAssembly betyder, at hele klasser af WebAssembly-målrettet software ikke kan skrives på disse sprog. Forslaget om at tilføje threading til WebAssembly bruger C ++ threading-modellen som en af sine inspirationskilder.
Bulkhukommelseshandlinger og SIMD
Bulkhukommelsesoperationer og SIMD-parallelitet (enkelt instruktion, flere data) er must-haves til applikationer, der slibes gennem bunker af data og har brug for indbygget CPU-acceleration for at forhindre kvælning som maskinindlæring eller videnskabelige apps. Der er forslag på bordet for at tilføje disse funktioner til WebAssembly via nye operatører.
Sprogkonstruktioner på højt niveau
Mange andre funktioner, der overvejes for WebAssembly, kortlægges direkte til højkonstruktioner på andre sprog.
- Undtagelser kan emuleres i WebAssembly, men kan ikke implementeres indbygget via WebAssemblings instruktions sæt. Den foreslåede undtagelsesplan involverer primitiver til undtagelser, der er kompatible med C ++ - undtagelsesmodellen, som igen kan bruges af andre sprog, der er sammensat til WebAssembly.
- Referencetyper gøre det lettere at videregive objekter, der bruges som referencer til værtsmiljøet. Dette ville gøre affaldsindsamling og en række andre funktioner på højt niveau lettere at implementere i WebAssembly.
- Haleopkald, et designmønster, der bruges på mange sprog.
- Funktioner, der returnerer flere værdierf.eks. via tupler i Python eller C #.
- Tegnudvidelsesoperatører, en nyttig matematikoperation på lavt niveau. (LLVM understøtter også disse.)
Fejlfindings- og profilværktøjer
Et af de største problemer med transpileret JavaScript var vanskeligheden ved debugging og profilering på grund af manglende evne til at korrelere mellem den transpilerede kode og kilden. Med WebAssembly har vi et lignende problem, og det behandles på en lignende måde (kildekortsupport). Se projektets note om support til planlagt værktøj.
