Vody webového vývoje před několika dny rozbouřila zpráva o novém jazyce pro web, nazvaném WebAssembly. O co se jedná, v čem je tato technika inovativní a co to znamená pro nás, webové brouzdače i JavaScriptové lopaty?
Kapitola první: JavaScript
Pro správné pochopení konceptů a přínosů WebAssembly se musíme nejprve ohlédnout za spletitou historií webových prohlížečů a programovacích jazyků v nich dostupných. Historický exkurz nebude dlouhý, ale pomůže nahlédnout, proč a kam směřují aktuální trendy.
JavaScript je tu s námi již přes dvacet let a za tu dobu prošel několika verzemi. Už od té první o místo v prohlížečích soupeřil s jazykem VBScript, který se objevil hned v roce 1996. Časem přibývala další konkurence: applety v jazyce Java, Flash, Silverlight, Adobe Air, Dart… ukázalo se však, že svrhnout JavaScript z pomyslného trůnu programovacích jazyků v prohlížeči je jako pokoušet se soupeřit v pití s Moravákem. Mnozí to zkusili, ale nakonec stejně padli.
Důvodů je několik. JavaScript měl výhodu prvenství; stavěl na osvědčené syntaxi jazyka C a svou expresivitou dovedl na pár řádcích vytvořit to, co v jiném jazyce vyžadovalo mnoho práce. Programátor se nemusel starat o správu paměti (k tomu je tu Garbage collector) a měl přímý přístup k HTML dokumentu. I přes některé nepochybné neduhy se tak stal JavaScript populárním pro vývojáře-nováčky a dnes tvoří vstupní nástroj pro tvorbu bohatých interaktivních stránek.
To ovšem neznamená, že je JavaScript bez chyb a že není prostor ani motivace pro hledání dalších vylepšení jak jazyka samotného, tak jeho konkrétních implementací a souvisejících rozhraní. Velmi výrazně se to ukázalo v roce 2008, kdy Google uvedl první verzi prohlížeče Chrome. Ta stavěla na zbrusu novém interpretru JavaScriptu, nazvaném V8 – šlo o horkou technologickou novinku, která v roce uvedení výkonem výrazně převyšovala veškerou tehdejší konkurenci. Velkou měrou za to mohla technika zvaná JIT (Just-In-Time), která vykonávaný JavaScript v některých případech nejprve předkompiluje do nativního kódu, který může být následně spouštěn řádově rychleji.
Po syntaktické stránce dochází k vylepšování jazyka uváděním nových verzí. Ta aktuální, ES2015, byla definitivně dokončena teprve před pár dny. Práce na ní ovšem započaly již v roce 2008, to je dlouhá doba. Dnes se proto daří takovým jazykům, které nejsou v prohlížeči přímo podporovány, ale které je možno transpilovat (toto nezvyklé označení se používá pro kompilaci, kdy výstupem není nativní kód, ale jiný jazyk) do JavaScriptu. CoffeeScript, ClojureScript, TypeScript… rozhodně je z čeho vybírat. Někdo upřednostní změny v syntaxi, jiný statickou typovou kontrolu, další programátor použije vlastní dialekt pro jiné řízení asynchronního toku kódu. Možností je v tomto směru mnoho.
Kapitola druhá: asm.js
Pojďme se nyní soustředit na výkon jazyka. Google Chrome při svém uvedení jasně ukázal, že na poli optimalizací jednotlivých interpretrů je rozhodně ještě mnoho práce. Za posledních několik let tak v důsledku konkurenčního boje doznaly jednotlivé implementace (V8 v Chrome, SpiderMonkey ve Firefoxu, JavaScriptCore v Safari) velkých změn a dnes již všechny obsahují mnoho různých forem techniky JIT i dalších optimalizací. Tyto triky ale zvolna naráží na pomyslný strop dostupných možností a tak je čas poohlížet se po alternativních způsobech urychlení vykonávání JavaScriptu.
Ve výpočetní technice je optimalizace často řízena principem něco za něco: uspoříme procesorový čas a zabereme paměť cachí; investujeme do minifikace kódu a tak snížíme jeho výsledný objem; rozložíme zátěž přes více serverů, čímž zmenšíme průměrnou dobu odpovědi. U JavaScriptu a jeho optimalizací nejvíce narážíme na ta místa, kde je jazyk dynamický: funkce pracující s proměnným počtem parametrů, změny typů proměnných za běhu, polymorfní volání, funkce eval().
Nabízí se tedy následující trik: omezíme sami sebe v možnostech, které nám jazyk nabízí, a na oplátku dostaneme vyšší výkon. Na tomto principu funguje asm.js, jazyk tvořený dobře optimalizovatelnou podmnožinou JavaScriptu. Jak vypadá kód v něm napsaný?
function strlen(ptr) { // calculate length of C string
ptr = ptr|0;
var curr = 0;
curr = ptr;
while (MEM8[curr]|0 != 0) {
curr = (curr + 1)|0;
}
return (curr - ptr)|0;
}
Na první pohled vidíme časté použití výrazu |0, tedy přetypování na 32bitový integer. To garantuje typovou stabilitu. Dále zcela odpadá práce s Garbage Collectorem, veškerá paměť je ručně spravována ve velkém poli ( MEM8 zde nabízí přístup k hodnotám po osmicích bitů, tedy bajtech). Tento kód je, z pohledu interpretru-překladače, skvěle optimalizovatelný. Pro člověka je ovšem obtížně čitelný a málokdo by chtěl něco takového psát ručně. Asm.js je proto používán jako transpilační cíl – vezmeme kód psaný řekněme v C++, vygenerujeme z něj kód v asm.js a ten pak spustíme v každém prohlížeči na světě.
Mimochodem: prohlížeč si ovšem sám od sebe nevšimne, že se jedná o asm.js a nikoliv o plnohodnotný JavaScript. Pokud tedy chceme, aby pro jeho vykonávání použil relevantní optimalizace, musíme mu to dát najevo. To učiníme tak, že na první řádek souboru s asm.js přidáme řetězec "use asm";.
Asm.js je tu s námi od roku 2013 a dokázal si získat značnou popularitu – lze do něj překládat C++, Perl, Python a Ruby; existují porty pro Vim, SQLite, GPG a graphviz; v asm.js lze použít Unity i Unreal Engine 4.
Kapitola třetí: WebAssembly
Poměrně přímočarým krokem dalších optimalizačních ambicí na webu je právě WebAssembly. Jedná se o binární formát, reprezentující abstraktní syntaktický strom (AST) zdrojového kódu. Je zde tedy zcela opuštěna vazba na konkrétní syntaxi JavaScriptu, ze které by WebAssembly vzniklo – soubor ve formátu .wasm (tedy zdrojový kód WebAssembly) má být možné vytvářet z jiných jazyků bez nutnosti použití JavaScriptu jako mezikroku.
Takové řešení s sebou jednak nese úsporu objemu přenášených dat, druhak pak odpadá nutnost parsovat zdrojový kód a provádět jeho syntaktickou analýzu. WebAssembly je tedy něco jako syrový obsah paměti interpretru JavaScriptu poté, co dojde ke kompletnímu načtení a rozparsování zdrojových dat. A podle předběžných měření taková úprava stojí za to: už v této rané fázi projektu se načítání wasm ukazuje jako dvacetkrát rychlejší, než načítání korespondujícího JavaScriptu. A to je klíčové – zejména v době, kdy se internet přesouvá na mobilní zařízení se slabými procesory a pomalými datovými linkami.
Za zmínku též stojí, že součástí projektu WebAssembly má být výhledově i textový formát, korespondující 1:1 s binárním zápisem. Čitelná forma kódu se hodí pro ladění a hledání chyb, neboť interpretr dovede převést místo výskytu chyby z binárního do textového formátu a programátorovi tak čitelným způsobem ukáže, kde je v kódu problém. O textovém formátu se toho ovšem zatím moc neví, krom toho, že se dost možná vůbec nebude podobat JavaScriptu (není k tomu žádný důvod).
Tím, že WebAssembly používá vlastní binární formát, odpadá nutnost kompatibility se syntaxí tohoto jazyka. To otevírá prostor pro rychlejší aktualizace, výkonová vylepšení a další změny, které by se při vazbě na zpětnou kompatibilitu s JS navrhovaly jen obtížně.
Stav projektu WebAssembly
Autor jazyka JavaScript, Brendan Eich, odhalil projekt WebAssembly 17. června. Repozitář projektu na GitHubu však odhaluje, že práce na WebAssembly probíhají už několik měsíců a to ve velmi slibném zastoupení: účastní se Mozilla, Microsoft, Google i Apple. Taková technologická shoda se mezi nejsilnějšími hráči na trhu jen tak nenajde.
Projekt je zatím nicméně stále v plenkách. Zájemci mohou obhlédnout existující specifikace a další dokumenty projektu, k dispozici je též experimentální nástroj pro konverzi z wasm do asm.js. Existuje i patch pro V8, který přináší možnost načítání wasm souborů ve V8, a tím pádem i v Google Chrome a Node.js.
Dalším krokem jsou úpravy existujících překladačů tak, aby uměly generovat kód wasm. První bude v tomto směru patrně Emscripten, který je již nyní používán pro transpilaci do asm.js. S podporou dalších překladačů pak bude už jen vzrůstat počet jazyků, jejichž zdrojový kód bude možno reprezentovat ve formátu wasm, a tím pádem spouštět v běžných webových prohlížečích.
To mě zajímá, kde se dozvím víc?
K dispozici je W3C Community Group, neformální uskupení zúčastněných stran. S ohledem na syrovost projektu k dnešnímu dni však fakticky schází konkrétní ukázky, finální dokumenty či implementace.
Kromě oficiálních dokumentů se o projektu WebAssembly můžeme více dozvědět například na stránkách Axela Rauschmayera, jehož články o JavaScriptu na webu 2ality.com jsou vyhledávány v mnoha vývojářských komunitách.
Diskutovat lze též na IRC kanálu #webassembly v síti irc.w3.org. Na praktické použití a skutečné implementace technologie WebAssembly však bude nutné ještě nějakou dobu počkat.
Konec JavaScriptu?
Na závěr článku je důležité zmínit, že WebAssembly rozhodně není projektem s cílem nahradit JavaScript. Jednak nás historie učí, že tento jazyk v jeho současné podobě z internetu vymýtit nelze, druhak projekt WebAssembly míří jinam. Do míst, kde JavaScript a jeho výkon nestačí (a z definice jazyka stačit nemůže); tam, kde nás zajímá možnost využití existujícího kódu napsaného v jiném jazyce; pro případy, kdy potřebujeme performance-critical kód a nevadí nám, že nebude psán v čitelném a expresivním JavaScriptu.
Očekává se tedy, že běžný webař bude i nadále psát své malinké skripty i veliké SPA v tradičním ES2015. Ale čas od času bude ve svém projektu moci použít komponentu (řekněme knihovnu zlib či třeba SDL) z jiného jazyka pomocí jasně definovaného rozhraní a s přidanou hodnotou předvídatelného výkonu blízkého nativnímu kódu.
Jak moc a jak rychle se WebAssembly rozšíří, to dopředu samosebou nikdo neví. Ale projekt má dobře našlápnuto, odborná veřejnost ho přivítala s otevřenou náručí, a tak to vypadá, že aplikace na webu čekají skvělé časy!
ČLÁNKY DO MAILU