WebAssembly: összefogással jön a webes bájtkód

Fantasztikusan népszerűvé vált mára a JavaScript (JS), szerepe pedig ezzel együtt egyre inkább átalakul. A webes alkalmazások után már a szerveroldalon is teret hódító JS olyan köztes nyelvvé alakul, amely mindenhol tud futni, maga a programozás azonban már nem ebben, hanem valamelyik fejlettebb nyelvben (például TypeScript, Dart, stb.) folyik, amely JavaScriptre fordítódik és így, ebben a formában fut. Ezt a trendet igyekszik az ES6 (a JavaScript következő verziója) visszafordítani, azonban egyelőre nem látszik a kezdeményezés sikere, az alternatív, JS-re forduló alternatívák kifejezetten sikeresek.

Bájtkód - webre

A logika továbbgondolását Brendan Eich, a JavaScript atyja (korábban a Mozilla CEO-ja is volt egy ideig) jelentette be saját blogján: "Ma örömmel jelentem be, hogy megkezdődött a sokböngészős munka a WebAssemblyn, amely a webes biztonságos kód új köztes megjelenítése." A WebAssembly célja teljesen kiváltani a JavaScriptet ezen a poszton és egy alternatív, magasan optimalizált kódreprezentációt adni, amely a JavaScripthez hasonlóan biztonságosan, a rendszertől teljesen elválasztva futtatható - mivel ez alapvetően webes kódhoz készült, így alapelvárásnak számít.

A WebAssembly (vagy wasm) bináris szintaktikát használó alacsony szintű kód (bájtkód), amely nem tartalmaz hardverspecifikus elemeket. A bájtkód futtatásáról egy virtuális gép gondoskodik, ez utóbbi felel majd azért, hogy a kód megkapja az aktuális hardverplatformon elérhető optimalizációkat - pontosan úgy, ahogy a Java esetében is történik. A fejlesztők tervei szerint a WebAssembly az asm.js szintjének felel majd meg induláskor, hosszabb távon azonban eltávolodik majd a JavaScript szemantikájától, hogy jobban tudja támogatni a többi, JS-től eltérő nyelv objektumait.

^{Az asm.js helyét töltheti ki a WebAssembly}

Hello, itt az idei SYSADMINDAY! Szabadtéri helyszínen idén is megrendezzük a hazai Sysadmindayt. Melós hónapok után ez egy jó lehetőség, hogy találkozzunk barátokkal, kollégákkal.

Az új bájtkód formátum egyébként az asm.js logikus továbbgondolásaként is felfogható, ugyanazt szeretné elérni, viszont egyet előre lépve. Az asm.js a JavaScript egy szűkített, teljesítményre optimalizált verziója, amely kidobja a nyelv teljesítmény szempontjából problémás részeit (és a szemétgyűjtést), viszont minden JavaScript VM-en képes futni, tehát visszafelé is kompatibilis. Az asm.js problémája a fejlesztők szerint, hogy a kód első feldolgozása (parsing) rendkívül hosszú ideig tart, első látogatáskor mobilon akár 20-40 másodperc (!) is lehet ez a lépcső, ehhez képest a WebAssembly az előzetes tesztek szerint akár 20-szoros gyorsulást is hozhat.

Az asm.js-t is köztes nyelvnek szánták a fejlesztők, amelyre C/C++ és egyéb nyelvek is lefordíthatóak. Mivel az asm.js már viszonylag széles körű támogatással rendelkezik, a WebAssembly erre az elvégzett munkára épít. A kezdeti paritásra azért van szükség, hogy a WebAssembly bájtkód polyfilling (visszamenőleges kompatibilitást biztosító köztesréteg) segítségével visszamenőlegesen kompatibilis maradjon - legalábbis amíg a széleskörű támogatás meg nem jelenik a nagyobb böngészőkben.

A polyfill réteg prototípusa már elérhető, az Emscripten már képes futtatócélként olyan kódot előállítani, ami ezen fut. Eich bejegyzése szerint hamarosan a natív dekóderek is megjelennek majd, és a Chrome-ban dolgozó V8 motor natív futtatója is hamarosan célegyenesbe érkezik, ehhez az Emscripten már elő tudja állítani a wasm fájlokat.

^{Végre van válasz a kérdésre}

Azt fontos megjegyezni, hogy a WebAssembly jelenleg a fejlesztés kezdeti fázisában, az első működő prototípusok szintjén tart, a kiforrott, éles környezetben is használható verziókig hosszú hónapoknak (akár éveknek) kell még eltelni. Ugyanígy a WebAssemblyt formalizáló szabványra is sokat kell még várni, Eich szerint azonban minden böngészőben lesz majd gyors, natív wasm-dekóder a közeljövőben.

Kulcsfontosságú, hogy a projektet az első pillanattól kezdve felkarolta a Google és a Mozilla mellett a Microsoft is, a munkában pedig a WebKit fejlesztői is részt vesznek, így közvetve az Apple is támogatja a projektet. Az össznépi összefogás jegyében a fejlesztést nem egy cég, hanem a független W3C keretében működő WebAssembly Community Group irányítja majd, így egyik szereplőnek sem lesz kizárólagos befolyása a készülő technológiára. A Google mind V8-as, mind PNaCl csapatát ráállította a projektre, a Mozillától az asm.js és Emscripten szakemberek dolgoznak rajta, és a Microsoft is kulcsfejlesztőket delegált.

Szerveroldalon is?

A bejelentésben nincs róla szó, de a WebAssembly nyilván nagyon jó megoldás lehet a szerveroldali JavaScript (node.js) kiváltására-turbózására is. Ugyanazok a virtuális gépek, amelyek a böngészőben jelentős sebességnövekedést tudnak elérni, erre szerveroldalon is képesek lehetnek. Izgalmas kérdés, hogy a backend technológiák hogyan kapaszkodnak fel majd erre a szerelvényre, érdemes lesz a fejleményeket ezen az oldalon is figyelni.

A WebAssembly fejlesztői gondosan ügyeltek arra, hogy a bináris bájtkód bevezetése ne menjen a weben hagyománynak számító olvashatóság rovására, így a HTML/CSS/JS-hez hasonlóan a WebAssembly forráskódja is olvasható lesz. Ezt a Text Format funkció szolgálja, amely "természetesen illeszkedik a webhez, ahol minden forrás megnézhető". A szöveges formátum a fejlesztők ígérete szerint ekvivalens és izomorf lesz a bináris formátummal, vagyis a kettő egymásból tetszőlegesen oda-vissza alakítható majd.

A WebAssembly koncepciójával való ismerkedést érdemes az eredeti bejelentéssel és az itt található FAQ-kal kezdeni.

Frissítés: ugyan az Apple hivatalosan nem vesz részt a Community Group munkájában, a Safari alapját képező WebKit képviselteti magát, így gyakorlatilag biztosra vehető, hogy ez a böngésző is támogatni fogja majd a WebAssembly-t. A cikket ennek megfelelően pontosítottuk.