Google Developers Japan

• Wasm 版 FFMPEG は、ウェブアプリで効率的に動画を扱えるようにします。標準化されている WebCodecs でも同じようなエンコードやデコードが可能ですが、対応ブラウザはまだ限られています。
  • WebAssembly は、Google Meet のビデオ通話の背景ぼかしに使われており、この機能に関する専用の標準提案が行われています。
    • Web SQL は標準化され、何年も前から Chrome に搭載されていますが、多くのブラウザでサポートされることはありませんでした。Wasm 版 SQLite は Web SQL に替わる機能です。Web SQL は、今後 Chrome から削除される予定です。
      • Universal Scene Descriptor（USD）は Safari に搭載されていますが、他のブラウザでは利用できません。
        
        

        この新しい開発パラダイムがもたらすメリット

        イテレーションの高速化

        標準化と承認を経なくても機能を公開できるので、イテレーション サイクルが年単位から日単位、場合によっては時間単位にまで短縮できます。オリジン トライアルなどのアプローチを使えば、多くの試験運用を行うことはできますが、それでも週単位や月単位のイテレーションが必要になります。イテレーションの速度を変えるということは、その対象自体を抜本的に変革するということです。

        機械学習などの分野は進展が速いので、標準ベースのアプローチではついていくことができません。設計が標準化を経てクロスブラウザ実装に移ったころには、すでに新たな進展があり、プロセス全体をやり直さなければならなくなってしまいます。

        とは言うものの、標準化が不可欠なことも多い点は変わりません（後述のデメリットのセクションを参照）。標準化が適している場合は、当然標準化を試みる必要があります。

        さまざまなブラウザをすぐにサポート

        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