WebAssemblyとは何でしょうか？C/C++をコンパイルして使えるのでしょうか？ブラウザで動作するのでしょうか？この分かりやすい解説で説明させてください。

コードコーナー 私たちと同じように、皆さんも最近WebAssemblyについてよく耳にするようになったのではないでしょうか。今日は、フリーランスのソフトウェアエンジニアであるBen Jamesが、WebAssemblyの誕生、現状、そしてクロスプラットフォーム開発の将来における役割について解説します。

ウェブの始まり

WebAssemblyの必要性を理解するために、1990年代に遡りましょう。NetscapeとSunは協力し、初期のウェブブラウザの一つを必死に開発していました。当時、彼らは将来何が起こるのか、ブラウザで何ができるようになるのか、全く予想していませんでした。また、異なるブラウザを開発する他社とも競合していました。この組み合わせにより、JavaScriptが誕生した当時、彼らは非常に速いペースで開発を進めていました。

これは、JavaScriptが「風変わりな」言語と見なされる理由をある程度説明できるかもしれません。JavaScriptで構築されたインフラやアプリケーションは膨大ですが、完璧な言語だと言う人はいません。しかし、インタラクティブなワールドワイドウェブを構築するというJavaScriptの根本的な目標は、見事に達成されています。

しかし、今は2020年。人々はブラウザにますます多くのものを詰め込んでいます。コンテンツ、グラフィック、広告、そして高解像度。新しいアプリケーションを開発する企業なら、なぜネイティブアプリにしないのでしょうか？

ウェブアプリがインストール不要、ディスク容量の占有なし、そして何よりも、あらゆるプラットフォームで単一のコードベースのみを保守するだけで済むという利便性を提供できるのであれば、製品やアプリケーションをブラウザで開発しない理由は全くありません。これらすべてに加え、シングルページアプリケーション（SPA）の台頭を考慮すると、現代のウェブにとってブラウザのパフォーマンスがいかに重要であるかは容易に理解できます。

そのため、JavaScriptが開発者やユーザーの要求に追いつけないのも無理はありません。そこで2015年にWebAssembly（またはWasm）が発表されました。驚くべきことに、WebAssemblyの発表からわずか2年後の2017年11月には、すべての主要ブラウザでサポートされました。この標準規格の一部として発表された目標の一部を以下に示します。

• 幅広いプラットフォームで利用可能な一般的なハードウェア機能を活用します (移植性と効率性)。
• バイナリ形式とテキスト形式を作成します。
• 既存の Web プラットフォーム内で実行し、適切に統合します (JavaScript との間の同期呼び出しを許可し、同一オリジンおよび権限のセキュリティ ポリシーを適用するなど)。

もう一つの目標は、ブラウザ以外への埋め込み、つまりブラウザ外での実行をサポートすることです。これは非常にエキサイティングな取り組みですが、後ほど詳しく説明します。まずは、WebAssembly の基本的な仕組みを見てみましょう。

Wasm 101

WebAssemblyはブラウザ内で直接実行される低水準言語です。あらゆるブラウザやプラットフォームで実行可能でありながら、言語として可能な限り低水準であるという考えに基づいています。そのため、ソースコードから機械語への変換距離が大幅に短縮されるため、ブラウザにとってWebAssemblyコードの実行はJavaScriptの実行よりもはるかに容易になります。

嬉しいことに、WebAssemblyはC/C++やRustなどの言語からコンパイルするだけで使えるので、コードを書かずに使えるのです。他の言語でも使えますが、メモリ管理が明確に記述されている言語から始めるのが一番簡単です。

C/C++をWasmにコンパイルできるようになったことで、既存のコードベースやロジックをブラウザに移行することが可能になりました。例えば、AutoCADとFigmaはどちらもWebAssemblyを採用し、優れたパフォーマンス結果を報告しています。

しかし、WebAssembly を記述する必要がある場合、2 つの形式が用意されていることを知っておくと安心です。配布用のバイナリ形式 (.wasm) と、人間が読めるテキスト形式 (.wat) です。.wat 形式と .wasm 形式は全く同じものを表します。.wasm ファイルは、同等の JavaScript ファイルよりもブラウザに送信する際のサイズが小さいことが多いため、パフォーマンスの向上だけでなく、ネットワークのメリットも得られます。

素晴らしいですね。開発者の採用が増えるにつれて、ブラウザ上でより高速でリッチなアプリケーションが実行されるようになるはずです。さらにエキサイティングなのは、主流のJavaScriptライブラリがWasmを活用し始める時です。Wasm版のライブラリにアップデートするだけで、開発者は追加の開発コストをかけずにパフォーマンスを向上させることができます。

しかし、WebAssemblyの魅力はブラウザだけにとどまりません。近年、ハードウェアと最適化の面で最低限必要なレベルの言語が、様々な場面で役立つことが認識され始めています。実際、Dockerの創設者であるソロモン・ハイクス氏はかつてこうツイートしています。「もし2008年にWASMとWASIが存在していたら、Dockerを作る必要はなかっただろう」

ブラウザ外のWebAssembly

はい、そうですね。まるでJavaの2ラウンド目に挑戦しているように聞こえます。しかし、Wasmはブラウザ/サーバー間の移植性に適しており、JVMにはない重要な点がいくつかあります。

• 複数の言語のコンパイル ターゲットとして設計されています。
• 迅速にコンパイルされ、ストリーミング/ダウンロード中のコンパイルをサポートします。
• インターフェース ポリシーがよりシンプルになり、より安全になります。

これらすべてにより、Wasmは他のランタイムにメリットをもたらす独自の立場にあります。PythonやPHPなどで書かれたアプリケーションの場合、WebAssemblyはネイティブに近い速度で実行できるため、パフォーマンスを劇的に向上させることができます。C++やRustなどで書かれている場合、WebAssemblyが提供するサンドボックス機能はパフォーマンスコストをほとんどかけずにセキュリティを大幅に向上させることができます。

Wasm をブラウザー外で使うことについては憶測されていましたが、2019 年 3 月に WASI が発表されるまでは現実的ではありませんでした。WebAssembly をブラウザー外で実行したい場合、ファイルやネットワークなどの基本的なものにプラットフォームに依存しない方法でアクセスできる場合にのみ有用になります。

これらの機能は当初、ブラウザ向けに設計されたため、Wasm には組み込まれていませんでした。WASI は Web Assembly System Interface の略で、異なる OS 間でシステムコールへのアクセスを提供するモジュール式 API です。

結論

この段階では、皮肉な意見を言うのも無理はありません。もしWasmが本当に約束通りの性能なら、なぜもっと頻繁に使われていないのでしょうか？その答えは、単に時間の問題です。WebAssemblyはまだ初期段階にあり、新しいランタイム、ツールチェーン、そしてサンプルが次々とリリースされています。

そのため、現時点では WebAssembly を本番システムに実装するためのサポートに苦労するかもしれませんが、すぐに魅力的な選択肢になるでしょう。WebAssembly をしばらくフォローしてきた者として言えるのは、Wasm は非常に急速に進化しており、毎週新しい情報や変更が発生しているということです。®