Mozilla, Google, Microsoft, Appleは、Web向けのバイナリフォーマットを開発することを決定した。WebAssemblyと呼ばれ、このフォーマットは、ブラウザや他のエージェントでアプリケーションの実行を可能にし、任意のプログラム言語を対象にする可能性がある。
2年前、私たちはInfoQ上で、Web上のユニバーサルバイトコードのメリットと、それを作る難しさについて議論している (議論: ユニバーサルWebバイトコードは必要か？を参照)。最大の問題は、主要なブラウザメーカー間の不一致であった: Mozillaはasm.jsを押し、GoogleはPNaClを後押しし、AppleはFLTJITに取り組み、Microsoftはそれらのどれにも興味を示さなかった。だがそれは変わった。4社の主要ブラウザベンダーは、WebのバイナリフォーマットであるWebAssemblyやWASM/wasmを開発することに合意した。これはバイトコードと呼ばれているが、wasmは伝統的な意味でのバイトコードではないとBrendan Eich氏は述べる:“そしてWebAssemblyは圧縮ASTエンコーディングでありバイトコードスタックではありません。しー。誰にも言わないでください。お望みならバイトコードを呼ぶことができます。”
このプロジェクトはストレスモードだったが、GitHubにあらわれて、W3C Community Groupに公開された。WebAssemblyは、サーバー上のブラウザと他のJSエージェント、モバイルやIOTでJavaScript以外の言語で書かれたプログラムを許可することを意味する。このフォーマットは最終的にasm.jsとPNaClを置き換える。このプロジェクトの未決定の設計ドキュメントによると、WASMはバイナリを使用して“おり、その効果は: ダウンロードサイズが小さくなり、デコードを短縮し、巨大なコードベースでも迅速に起動することができる。” WASMは、開発者が使用しているデバッガや他のツールを使うことができる付属のテキストフォーマットを持っている。ツールは情報を失うことなく、あるフォーマットから他に変換することができるようになる。
WebAssemblyを実装する最初の一時的なステップは作られている: 対応するasm.jsコードにフォーマットを変換するため、すでに対応しているブラウザ上で実行することができる: Firefox, Edge, Chrome。この目的のためのpolyfillプロトタイプはすでに存在し、初期の結果は、バイナリフォーマットのgzipされたフォーマットは、対応するgzipされたasm.jsと比較して20-30%小さく、wasmデコーディングは、対応するasm.jsソースと比較して23倍高速に解析できる。WASMは、後にブラウザのVMでネイティブにサポートされる。
WebAssemblyは、最初にC/C++プログラムをWebに連れて行くだろうが、他の言語にそれを拡げることができるだろうか。LLVMバックエンドとclangの移植が計画されている。WASMは、“JavaScriptと同じセマンティック世界”で実行され、JavaScriptと相互の非同期呼び出しをサポートし、すべてのブラウザAPIにアクセスすることができ、JavaScriptプログラムに認められているセキュリティポリシーに準拠する。クライアントアプリケーションは、WASMで完全に書くか、ビジネスロジックをWASM、UIをHTML/CSS/JavaScriptで書くこともできる。
JavaScriptの20回目の誕生日直後で、EcmaのES6最終承認を発表と同じ日に発表され、WebAssemblyはJavaScriptにとってよいニュースとは言えない: WASMは、任意の言語をそれにコンパイルすることでWebでコードを実行することができる。JavaScriptは直接、他の言語と競合する。JavaやC#をWASMにコンパイルすることが期待できるだろうか？
WebAssemblyは、MozillaとGoogleからasm.jsとPNaClの各チームが開発に関与しており、それらの開発から学べるという恩恵がある。MicrosoftとAppleがこのプロジェクトをサポートするということは非常に頼もしい。唯一の問題は時間である: 通常、複数の大企業が開発するプロジェクトには多くの時間が必要になる。このようなケースでは、標準化プロセスは遅くなる。