Mozilla HacksのWhere is WebAssembly now and what’s next?を読みました。2017年2月に主要ブラウザがWebAssembly MVPの完了に合意したタイミングで、WebAssemblyがどこまで来ていて、次に何を目指すのかを整理した記事です。
この記事の中心は、MVPが「完成版」ではなく「安定して出荷できる最小の核」だという点です。WebAssemblyはこの時点で、ブラウザが既定で有効にしてよい段階へ進みました。一方で、DOMアクセス、共有メモリ、SIMD、例外処理、GC連携、ES module統合などは、将来機能として段階的に仕様化していく前提で語られています。
記事の要点
- 2017年2月28日、Chrome、Edge、Firefox、WebKitを代表するWebAssembly CGメンバーが、初期MVPのAPIとバイナリ形式について合意しました。
- MVPは、WebAssemblyを高速で実用できる安定したコアとしてブラウザが出荷できる状態を意味します。
- 古いブラウザ向けにはasm.js fallbackを使えるため、Emscriptenで同じアプリをWebAssembly版とasm.js版に分けて配布できます。
- JSからWebAssembly関数を呼ぶ際のtrampolining、ロード時間、streaming compilation、2段階コンパイラなど、実装側の高速化余地が説明されています。
- 将来機能として、DOMへの直接アクセス、SharedArrayBufferを使う共有メモリ並行処理、SIMD、例外処理が挙げられています。
- 性能以外の改善として、ソースレベルの開発者ツール、ガベージコレクション連携、ES6 module統合も期待されています。
参照リンクから見えたこと
記事中のW3Cメーリングリストの合意メールも確認しました。そこでは、MVPのJavaScript APIとバイナリ形式が、これ以上は実装経験と利用実績なしに設計を進めにくい段階まで来たため、Browser Previewを終えると説明されています。つまりMVP完了は、仕様検討の終了ではなく、実装と利用から学ぶフェーズへの移行です。
MDNのWebAssemblyページを見ると、現在はcompileStreaming、instantiateStreaming、Memory、Table、Exception、TagなどAPI群も整理されています。2017年の記事で「将来」とされていた一部の話は、現在のWebAssembly JavaScript APIや仕様群の中でかなり具体化しています。
また、webassembly.orgは、仕様、ドキュメント、コミュニティへの入口になっています。この記事の時点でWebAssemblyは、単一ブラウザの実験ではなく、主要ブラウザが合意した標準技術として前へ進み始めたことが分かります。
気づき
今回の気づきは、MVPという言葉の意味です。プロダクト開発では「最低限動くもの」と受け取られがちですが、WebAssemblyのMVPは「長く互換性を保ちながら出荷できる最小核」でした。将来機能を急いで詰め込むのではなく、まず後方互換性のある土台を固め、実装経験を通じて次を決める。この順番が、標準技術としての強さにつながっています。