WebAssembly: producenci przeglądarek wspólnie pracują nad zastąpieniem JavaScriptu kodem bajtowym

Jakby bowiem JavaScriptu nie ulepszać, wciąż przypomina tonieco malowanie szminką świni. Główne zalety tego języka, czyliniezależność od architektury sprzętowej i uruchamianie kodu wizolowanym środowisku przeglądarki, bez dostępu do interfejsówsystemu operacyjnego nie są w stanie przeważyć wad, jakimi sąduży narzut wynikający z konieczności każdorazowej interpretacjitekstowego ciągu znaków, nieprzemyślana składnia języka, dużeproblemy z systemem typów zmiennych i obiektami, czy osobliwaskładnia wyrażeń regularnych, wyglądająca jakby pochodziła zPerla. Jest tak tym bardziej, że zalety JavaScriptu możnadostarczyć bez jego wad, jak to się dzieje w środowiskachuruchomieniowych dla kodu bajtowego, takich jak .NET czy Java.

Czytelnicy oczywiście pamiętają próby wprowadzenia Javy czy C#do przeglądarek – niesławne wtyczki Oracle'a i Microsoftupozwalały na uruchamianie kodu bajtowego w kontekście stronyinternetowej. Rozwiązanie to miało jednak swoje wady, nie pozwalałona modyfikowanie obiektów HTML, tak naprawdę uruchamialiśmyaplikację nie mającą ze stroną internetową nic wspólnego.Trochę lepszym podejściem okazał się Portable NativeClientGoogle'a, pozwalający uruchamiać kod bajtowy w bezpiecznejpiaskownicy i poprzez interfejs przeglądarki modyfikować zawartośćobiektowego modelu dokumentu HTML – nigdzie jednak poza Chrome nieznalazł on zastosowania.

Szansa na wydajny kod bajtowy w przeglądarce pojawia się jednakna nowo. „W przeglądarce” nie jest najlepszym określeniem,należałoby napisać „w przeglądarkach”, gdyż w ramach grupyprojektowej W3C nad rozwiązaniem o nazwie Web Assembly (wasm)pracują przedstawiciele czołowych producentów przeglądarek. Wasmma być łatwym w przenoszeniu kodem bajtowym, znacznieefektywniejszym w kompilacji niż asm.js, nie mówiąc już o „gołym”JavaScripcie. W przeciwieństwie do JavaScriptu oferuje normalne typydanych. Ma też być łatwy w rozszerzaniu, tak by objąć dodatkowe,specjalizowane instrukcje procesora.

Najważniejsze jest jednak to, że kod wasm będzie dostępny wdwoistej postaci. Binarna reprezentacja dla kompilatora orazodpowiadająca jej forma tekstowa, dla programisty i debuggera.Wykorzystanie binarnej reprezentacji przynosi ogromne korzyści –jej dekodowanie ma być nawet 23 razy szybsze od odpowiadającejformy tekstowej (kodu asm.js), a skompresowany rozmiar o 20-30%mniejszy.

Żadna ze współczesnych przeglądarek nie uruchomi oczywiściekodu wasm. Na implementację w stabilnych wersjach w tym roku nie maraczej co liczyć. Do tego czasu kod bajtowy będzie uruchamianydzięki działającej w przeglądarce warstwie wypełniającej(polyfill), czyli skryptowi w JavaScripcie, który przekształci kodwasm do kodu zgodnego z podzbiorem JavaScriptu asm.js. Z pierwszycheksperymentów wynika, że nawet taka niebezpośrednia metoda jestwydajniejsza, niż uruchamianie czystego kodu JavaScriptu wprzeglądarce.

Zanim ukończona zostanie finalna wersja Web Assembly, miniejeszcze sporo czasu. Prace możemy obserwować naGitHubie, jest tam już dostępna dokumentacja, w tym założeniaprojektowe, prototypy narzędzi, biblioteki polyfill – wszystko,czego potrzeba na start. Najważniejsze, że jest tu jednak duchwspółpracy między wiodącymi producentami przeglądarek. O swoimzaangażowaniu poinformowali ludzie z Mozilli,Google,Microsoftu,a nawet Apple.Dzięki takiemu postawieniu sprawy możemy liczyć, że aplikacjewebowe pod względem wydajności wejdą na poziom do tej porynieosiągalny – i co najważniejsze, będą działały w każdejnowoczesnej przeglądarce, bez konieczności korzystania z wtyczek.