WebAssembly は、ウェブの新しいデベロッパー機能の作成方法を根本的に変革します。ブラウザの相互運用性を維持するため、新しいウェブ機能は厳格な標準化プロセスを経て、クロスブラウザで実装される必要があります。数十年にわたる大規模な取り組みにより、ブラウザの機能は驚くべきレベルに達していますが、この過程には時間がかかる場合があり、すべての機能をウェブに組み込まなければならないわけでもありません。これまで何年もかけて、高レベルの機能の構成要素となる低レベル機能に注力してきましたが、現在私たちは新たな夜明けを目にしており、劇的に速いペースでさまざまな機能が登場しています。
ポータビリティと高パフォーマンス CPU アクセスを実現する WebAssembly が加わったことで、ウェブには低レベルの構成要素がすべてそろい、実に多様な新機能を構築できるようになりました。これらはすべて、数々の充実した機能やレンダリング手法などを備えた、ウェブ プラットフォーム全体という驚異的な土台のうえに成り立っています。
実例
WebAssembly のおかげで実現できた新機能はたくさんありますが、1 つのブログ投稿を丸ごと使ってその一部を紹介しています。
その中には、さまざまな理由で標準プロセスを通過できなかった機能も含まれています。また、現在標準化が進行中で、さまざまなブラウザで実装が進められているものもあります。
- WebAssembly は、Google Meet のビデオ通話の背景ぼかしに使われており、この機能に関する専用の標準提案が行われています。
この新しい開発パラダイムがもたらすメリット
イテレーションの高速化
標準化と承認を経なくても機能を公開できるので、イテレーション サイクルが年単位から日単位、場合によっては時間単位にまで短縮できます。オリジン トライアルなどのアプローチを使えば、多くの試験運用を行うことはできますが、それでも週単位や月単位のイテレーションが必要になります。イテレーションの速度を変えるということは、その対象自体を抜本的に変革するということです。
機械学習などの分野は進展が速いので、標準ベースのアプローチではついていくことができません。設計が標準化を経てクロスブラウザ実装に移ったころには、すでに新たな進展があり、プロセス全体をやり直さなければならなくなってしまいます。
とは言うものの、標準化が不可欠なことも多い点は変わりません（後述のデメリットのセクションを参照）。標準化が適している場合は、当然標準化を試みる必要があります。
さまざまなブラウザをすぐにサポート
wasm はさまざまなブラウザでサポートされているので、これを使って構築した機能もすべてのブラウザですぐに動作します。機能の相互運用性とクロスブラウザ実装は、デベロッパーにとって最大の悩みです。機能を低レベルプリミティブに移行することで、この懸念の大半を解消できます。
セキュリティの向上
この機能は厳格なセキュリティ サンドボックスがベースになっているため、ネイティブ実装された API よりも格段にセキュリティが向上します。たとえば、Flash がウェブから削除された大きな理由は、複雑なプラグインのセキュリティを十分に強化するのが難しすぎたためです。しかし、今は Flash を WebAssembly で実行でき、セキュリティの懸念の大半が解消されています。
デメリットと制限
複雑な問題に対するあらゆる新しいソリューションと同じく、WebAssembly にもデメリットや制限がないわけではありません。その中には、仕組み的に避けられないものもあれば、有望なソリューションが存在するものもあります。
ほとんどのウェブ開発で JavaScript の代替となるものではない
WebAssembly は JavaScript の代替ではなく、JavaScript が時代遅れになるわけでもありません。どちらかというと、WebAssembly は JavaScript の機能を拡張するものです。
WebAssembly は JavaScript を使わずにブラウザで動作させることはできません。また、他のウェブ機能にアクセスする場合は、JavaScript のインターフェースを通す必要があります。WebAssembly で実現するライブラリや新機能は、JavaScript API を介して使用されます。wasm モジュール同士の通信や、Web API との直接インターフェースも提案されていますが、これはまだ開発の初期段階です。
ページのバンドルサイズ
ユーザーランドに移動するロジックや機能が増えることで、ページのサイズも増大します。バンドルサイズの縮小は優れたユーザー エクスペリエンスにとって最重要なので、これは大きな問題になります。そのため、この機能を使ってバンドルサイズを肥大化させる前に、慎重に検討する必要があります。この点は、小さな e コマースやブログのサイトよりも、大型のウェブアプリで問題になる可能性があります。JavaScript を多用するフレームワークでも、これが長いこと問題になっています。この状況を改善するため、さまざまなソリューションが考えられるかもしれません。
問題を軽減できる可能性があるもう 1 つの手段は、ユーザーランドの人気機能に注目し、それを参考にして、どの機能を標準化してブラウザ自体に含めるかを判断するというものです。ユーザーランドで実績を積んだ機能なら、ブラウザに自信と確証を持って搭載することができます。そのため、標準と実装にまつわる作業も大幅に簡素化されます。WebCodecs は wasm でコンパイルした FFMPEG を、
手書き認識 API は
wasm でコンパイルしたバージョンを置き換えるものですが、これらはその好例となります。
デバイスの機能へのアクセス
WebAssembly などのプリミティブは、ほとんどが計算メカニズムであり、OS やデバイス自体にシステムのルート権限でアクセスする機能は一切提供されていません。ハードウェア アクセス（USB や Bluetooth）、画面やウインドウの管理、入力コントロール、ファイル システム、クリップボードなどの機能にアクセスする場合は、今後もプラットフォーム レベルの API が必要になります。Chromium の Fugu プロジェクトは、Chromium ベースのブラウザでこれらのすべての事例を実現しようとするものですが、他のブラウザでの実装も必要になります。
まとめ
WebAssembly は、すでにブラウザの新機能実現に活用されていますが、それ以上に、根本的に新しい方法で機能の開発方法にアプローチします。何かを改善する最善の方法は、その改善方法を改善することです。すると、2 次曲線的な成長を遂げることができます。どのような新しいパラダイムにもメリットとデメリットがあります。しかし、総合的に見れば、WebAssembly は、あらゆるブラウザとデベロッパーにとって新しいアプローチであると言えます。これを使って皆さんとともに開発を進めていくのが楽しみでなりません。
Posted by
Eiji Kitamura - Developer Relations Team
