WebAssembly primer: Kom i gang med WebAssembly

WebAssembly lover en helt ny type nett - raskere ytelse for brukerne, og mer fleksibilitet for utviklere. I stedet for å bli låst til å bruke JavaScript som det eneste språket for nettinteraksjon på klientsiden, kan en utvikler velge fra et bredt spekter av andre språk - C, TypeScript, Rust, Ruby, Python - og jobbe på det de er mest komfortable med.

Opprinnelig var den eneste måten å lage WebAssembly (eller WASM for kort) å kompilere C / C ++ -kode til WebAssembly ved hjelp av Emscripten verktøykjede. I dag har ikke bare utviklere flere språkalternativer, men det har blitt lettere å kompilere disse andre språkene direkte til WebAssembly, med færre trinn.

I dette stykket vil vi undersøke trinnene som kreves for å implementere WebAssembly-komponenter i en webapp. Fordi WebAssembly er et pågående arbeid, er trinnene svært avhengige av hvilket språk du bruker, og verktøykjeden vil sannsynligvis fortsette å endre seg i noen tid. Men akkurat nå er det mulig å skrive og distribuere nyttige, hvis minimale, WebAssembly-applikasjoner på en rekke språk.

Velg et språk som støttes av WebAssembly

Det første trinnet mot å distribuere et WebAssembly-program er å velge et språk som kan kompileres til WebAssembly som et mål. Det er en god sjanse for at minst ett av de viktigste språkene du bruker i produksjonen kan konverteres til WebAssembly, eller har en kompilator som kan avgi WebAssembly.

Her er frontløperne:

• C. Åpenbart. Den typiske måten å slå C-kode til WebAssembly er via Emscripten, siden C-to-Emscripten-to-WebAssembly var den første WebAssembly-verktøykjeden som fulgte med. Men andre verktøy dukker opp. En hel kompilator, Cheerp, er utviklet spesielt for å generere WebAssembly-applikasjoner fra C / C ++ -koden. Cheerp kan også målrette JavaScript, asm.js, eller en hvilken som helst kombinasjon av ovennevnte. Det er også mulig å bruke Clang-verktøykjeden til å bygge nyttelast på WebAssembly, selv om prosessen fortsatt krever mye manuell løfting. (Her er ett eksempel.)
• Rust. Mozillas programmeringsspråk for systemer, designet for å være både trygt og raskt, er en av de største kandidatene for innfødt WebAssemble-støtte. Utvidelser til Rust-verktøykjeden lar deg kompilere direkte fra Rust-kode til WebAssembly. Du må bruke Rust’s nattlig verktøykjede for å utføre WebAssembly-kompilering, så denne funksjonen bør betraktes som eksperimentell for nå.
• TypeScript. Som standard kompilerer TypeScript til JavaScript, noe som betyr at det igjen kan kompileres til WebAssembly. AssemblyScript-prosjektet reduserer antall trinn som er involvert, slik at strengt skrevet TypeScript kan kompileres til WebAssembly.

Flere andre språk begynner å målrette WebAssembly, men de er i en veldig tidlig fase. Følgende språk kan brukes til å bygge WebAssembly-komponenter, men bare på mer begrensede måter enn C, Rust og TypeScript:

• D. D-språket la nylig til støtte for kompilering og lenking direkte til WebAssembly.
• Java. Java bytecode kan kompileres på forhånd til WebAssembly via TeaVM-prosjektet. Dette betyr noen språk som avgir Java bytecode kan kompileres til WebAssembly - for eksempel Kotlin, Scala eller Clojure. Imidlertid er mange av Java API-ene som ikke kan implementeres effektivt i WebAssembly, begrenset, slik som refleksjon og ressurs-API-er, så TeaVM - og dermed WebAssembly - er bare til bruk for et delsett av JVM-baserte apper.
• Lua. Lua-skriptspråket har en lang historie med bruk som et innebygd språk, akkurat som JavaScript. Imidlertid er de eneste prosjektene som gjør Lua til WebAssembly, ved å bruke en utføringsmotor i nettleseren: wasm_lua legger inn en Lua-kjøretid i nettleseren, mens Luwa JIT-kompilerer Lua til WebAssembly.
• Kotlin / Native. Fans av Kotlin-språket, en spinoff av Java, har ventet spent på den fulle utgivelsen av Kotlin / Native, en LLVM-backend for Kotlin-kompilatoren som kan produsere frittstående binærfiler. Kotlin / Native 0.4 introduserte støtte for WebAssembly som et kompileringsmål, men bare som et bevis på konseptet.
• .Nett. .Net-språkene har ikke fullstendig støtte for WebAssembly ennå, men noen eksperimenter har startet. Se Blazor, som kan brukes til å bygge ensides webapper i .Net via C # og Microsofts “Razor” -syntaks.
• Nim. Dette kommende språket kompileres til C, så i teorien kan man kompilere den resulterende C til WebAss Assembly. Imidlertid er en eksperimentell back-end for Nim kalt nwasm under utvikling.
• Andre LLVM-drevne språk. I teorien kan ethvert språk som utnytter LLVM-kompileringsrammeverket kompileres til WebAssembly, siden LLVM støtter WebAssembly som et av mange mål. Dette betyr imidlertid ikke nødvendigvis at noe LLVM-kompilert språk vil kjøre som det er i WebAssembly. Det betyr bare at LLVM gjør det enklere å målrette WebAssemble.

Alle de ovennevnte prosjektene konverterer det opprinnelige programmet eller generert bytecode til WebAssembly. Men for tolket språk som Ruby eller Python, er det en annen tilnærming: I stedet for å konvertere appene selv konverterer man språket kjøretid inn i WebAssembly. Programmene kjøres som de er på den konverterte kjøretiden. Siden mange språkbrukstider (inkludert Ruby og Python) er skrevet i C / C ++, er konverteringsprosessen i grunn den samme som med alle andre C / C ++ -applikasjoner.

Dette betyr selvfølgelig at den konverterte kjøretiden må lastes ned til nettleseren før noen applikasjoner kan kjøres med den, noe som reduserer belastningen og parsetiden. En "ren" WebAssembly-versjon av en app er lettere. Dermed er kjøretidskonvertering i beste fall et stoppgap tiltak til flere språk støtter WebAssembly som et eksport- eller kompileringsmål.

Integrer WebAssembly med JavaScript

Det neste trinnet er å skrive kode på språket du har valgt, med litt oppmerksomhet om hvordan koden vil samhandle med WebAssembly-miljøet, og deretter kompilere den i en WebAssembly-modul (en WASM-binær), og til slutt integrere den modulen med en eksisterende JavaScript-applikasjon.

De nøyaktige trinnene for hvordan du eksporterer koden til WebAssembly vil variere enormt avhengig av verktøykjeden. De vil også avvike noe fra måten vanlige innfødte binærfiler er bygget for det språket. I Rust må du for eksempel følge flere trinn:

1. Sett opp nattlig bygge for Rust, med wasm32-ukjent-ukjent verktøykjede.
2. Skriv rustkoden din med eksterne funksjoner erklært som # [ikke-mangel].
3. Bygg koden ved hjelp av verktøykjeden ovenfor.

(For en detaljert oversikt over trinnene ovenfor, se Rust and WebAssembly Book på GitHub.)

Det er verdt å merke seg at uansett språk du bruker, må du ha minst et minimum av ferdigheter i JavaScript for å integrere koden med en HTML-grensesnitt. Hvis JavaScript-utdragene på siden i dette eksemplet fra The Rust and WebAssembly Book virker greske for deg, kan du sette av litt tid til å lære minst nok JavaScript til å forstå hva som skjer der.

Integrasjonen av WebAssembly og JavaScript gjøres ved å bruke Webmontering objekt i JavaScript for å lage en bro til WebAssembly-koden. Mozilla har dokumentasjon på hvordan du gjør dette. Her er et eget WebAssembly-eksempel for Rust, og her er et WebAssembly-eksempel for Node.js.

Akkurat nå er integrasjonen mellom WebAssembly-bakenden og JavaScript / HTML-fronten fortsatt den mest tungvint og manuelle delen av hele prosessen. For eksempel, med Rust, må broer til JavaScript fremdeles opprettes manuelt, via rådatapekere.

Imidlertid begynner flere deler av verktøykjeden å løse dette problemet. Cheerp-rammeverket tillater C ++ - programmerere å snakke med nettleserens APIer via et dedikert navneområde. Og Rust tilbyr wasm-bindgen, som fungerer som en toveis bro mellom JavaScript og Rust, og mellom JavaScript og WebAssembly.

I tillegg vurderes et forslag på høyt nivå for hvordan man skal håndtere bindinger til verten. Når den er ferdig, vil den gi en standard måte for språk som kompileres til WebAssembly for å samhandle med verter. Den langsiktige strategien med dette forslaget omfatter også bindinger til verter som ikke er nettlesere, men nettleserbindinger er kortvarig, øyeblikkelig bruk.

Feilsøking og profilering av WebAssembly-apper

Et område der WebAssembly-verktøyet fremdeles er i de tidligste stadiene, er støtte for feilsøking og profilering.

Inntil JavaScript-kildekart kom, var det ofte vanskelig å feilsøke språk som ble samlet til JavaScript, fordi den opprinnelige og kompilerte koden ikke lett kunne korreleres. WebAssembly har noen av de samme problemene: Hvis du skriver kode i C og kompilerer den til WASM, er det vanskelig å tegne sammenhenger mellom kilden og den kompilerte koden.

JavaScript-kildekart angir hvilke linjer i kildekoden som tilsvarer hvilke regioner i den kompilerte koden. Noen WebAssembly-verktøy, som Emscripten, kan også sende JavaScript-kildekart for kompilert kode. En av de langsiktige planene for WebAssembly er et kildekartsystem som går utover det som er tilgjengelig i JavaScript, men det er fremdeles bare i forslagsfasen.

Akkurat nå er den mest direkte måten å feilsøke WASM-kode i naturen ved å bruke nettleserens feilsøkingskonsoll. Denne artikkelen på WebAssemblyCode viser hvordan du genererer WASM-kode med et kildekart, gjør den tilgjengelig for nettleserens feilsøkingsverktøy og går gjennom koden. Merk at trinnene beskrevet avhenger av bruk av emcc verktøy for å avgi WASM. Du må kanskje endre trinnene avhengig av hvilken verktøykjede du har.