Hlavní navigace

WebAssembly slibuje podstatné zrychlení webů, konec JavaScriptu se ale nekoná

 Autor: Shutterstock, podle licence: Rights Managed
Ondřej Žára 29. 6. 2015

Mozilla, Microsoft, Google i Apple pracují na společném projektu, který má posunout dnešní webové aplikace na novou úroveň.

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.

EBF16

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!

Našli jste v článku chybu?
Lupa.cz: Proč jsou firemní počítače pomalé?

Proč jsou firemní počítače pomalé?

Podnikatel.cz: 5 věcí, které o EET ještě nevíte

5 věcí, které o EET ještě nevíte

Lupa.cz: Poučný příběh jednoho rozšíření pro Chrome

Poučný příběh jednoho rozšíření pro Chrome

Vitalia.cz: Očkované a neočkované děti spolu ve školce

Očkované a neočkované děti spolu ve školce

Podnikatel.cz: Letáky? Lidi zuří, ale ony stále fungují

Letáky? Lidi zuří, ale ony stále fungují

Podnikatel.cz: Byla finanční manažerka, teď cvičí jógu

Byla finanční manažerka, teď cvičí jógu

DigiZone.cz: DVB-T2 ověřeno: seznam TV zveřejněn

DVB-T2 ověřeno: seznam TV zveřejněn

Vitalia.cz: Tohle jsou nejlepší česká piva podle odborníků

Tohle jsou nejlepší česká piva podle odborníků

Vitalia.cz: Když bílkoviny, tak jíme ty nekvalitní

Když bílkoviny, tak jíme ty nekvalitní

Podnikatel.cz: Babišovi se nedá věřit, stěžovali si hospodští

Babišovi se nedá věřit, stěžovali si hospodští

Vitalia.cz: 7 příčin neplodnosti u žen: pravda a mýty

7 příčin neplodnosti u žen: pravda a mýty

Lupa.cz: Bude Google platit médiím za použití článků?

Bude Google platit médiím za použití článků?

DigiZone.cz: Nejnovější špičkové TV ve videu

Nejnovější špičkové TV ve videu

Vitalia.cz: Muž, který miluje příliš. Ženám neimponuje

Muž, který miluje příliš. Ženám neimponuje

Podnikatel.cz: „Lex Babiš“ Babišovi paradoxně pomůže

„Lex Babiš“ Babišovi paradoxně pomůže

Podnikatel.cz: Vytvořte si web sami. Redakční systém Tumblr

Vytvořte si web sami. Redakční systém Tumblr

Vitalia.cz: Tradiční čínská medicína a rakovina

Tradiční čínská medicína a rakovina

Podnikatel.cz: ČSSZ posílá přehled o důchodovém kontě

ČSSZ posílá přehled o důchodovém kontě

DigiZone.cz: Na jaká videa se vlastně díváme

Na jaká videa se vlastně díváme

Vitalia.cz: Voda z Vltavy před a po úpravě na pitnou

Voda z Vltavy před a po úpravě na pitnou