WebAssembly: összefogással jön a webes bájtkód
Google, Microsoft, Mozilla, WebKit - minden böngésző támogatni fogja a WebAssembly új szabványát. Az új technológia igazi áttörésnek ígérkezik a natív és a webes appok közötti teljesítménykülönbség eltüntetésére, amely Java-mintára elhozza a bájtkódot böngészős környezetbe is.
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
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
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.