WebAssemblyをWeb上で第一級言語にする

(hacks.mozilla.org)

21 ポイント投稿者 GN⁺ 2026-03-12 | 4件のコメント | WhatsAppで共有

WebAssemblyは2017年の初公開以降、C/C++ などの低水準言語の実行を支援しながら発展してきたが、依然としてWebプラットフォームでは第二級言語として扱われている
Web APIと直接相互作用できるのはJavaScriptだけであり、WebAssemblyではそのために複雑な**JSバインディングコード（glue code）**を書く必要がある
この構造はロード手順の複雑さ、性能オーバーヘッド、言語ごとのツールチェーン分断などにつながり、開発者体験を損なっている
Mozillaはこれを解決するためにWebAssembly Component Modelを提案し、JSなしでも標準化された方法でWeb API呼び出しとモジュールロードを可能にしようとしている
このモデルが定着すれば、WebAssemblyはブラウザ内の第一級実行環境として位置づけられ、一般の開発者でも容易に活用できる基盤が整う見込みだ

WebAssemblyが第二級言語として扱われる理由

WebAssemblyはJavaScriptを通してしかWebプラットフォームにアクセスできず、Web APIを直接呼び出す権限がない
- JavaScriptは<script>タグで簡単にロードできるが、WebAssemblyはJS APIを使った手動のロード処理が必要
- WebAssembly.instantiateStreaming() などの複雑なAPI呼び出しを経る必要があり、開発者はこれを暗記するかツールで自動化しなければならない
esm-integration提案は、JSモジュールシステムを通じて.wasmファイルを直接 import できるようにし、ロード手順を簡素化する
- <script type="module" src="/module.wasm"></script> の形で直接ロード可能

Web APIアクセスの制約

JavaScriptでは console.log("hello, world") の1行で済む作業が、WebAssemblyではJSメモリアクセス、文字列デコード、関数ラッピングなどの複雑な手順を要する
- WebAssemblyはconsoleオブジェクトやDOMにアクセスできないため、JS側でメモリ共有と関数 import/exportを通じて間接的に呼び出す必要がある
この過程で生成される**バインディングコード（glue code）**は言語ごとに異なり、embind、wasm-bindgen のようなツールで自動生成される
- しかし、ビルドの複雑化、ランタイムオーバーヘッド、言語間の非互換性といった問題が生じる

WebAssemblyが第一級言語になれていない技術的要因

コンパイラ統合の難しさ: 各言語のコンパイラは、JSおよびWebプラットフォーム統合コードを個別に生成しなければならず、再利用できない
標準コンパイラの非互換性: rustc --target=wasm で生成したファイルは、ブラウザでそのまま実行できない
- プラットフォーム統合を実装した非公式ツールチェーンを別途インストールする必要がある
ドキュメントエコシステムの偏り: MDNなどのWeb文書の多くはJavaScript中心に書かれており、他言語の利用者にとって参入障壁が高い
性能問題: JSバインディングを経由したDOM呼び出しは、直接呼び出しに比べて45%の性能低下が発生する
- Dodrioフレームワークの実験では、JS glueを取り除くとDOM変更の適用時間が半分に減少した
JavaScript依存: WebAssemblyを実務で活用するには結局JSを理解する必要があり、これは**抽象化の漏れ（leaky abstraction）**の問題につながる

WebAssembly Component Modelの登場

WebAssembly Component Modelは、複数の言語とランタイムで共通利用できる標準化された実行単位を定義する
- Web APIアクセス、モジュールロード、リンク処理をJSなしで直接実行できる
- さまざまな言語で生成でき、ブラウザやWasmtimeなど複数のランタイムで実行をサポートする
**WIT（Interface Description Language）**を通じて必要なAPIを宣言し、コンポーネント内部から直接呼び出せる
- 例:
```
component {
  import std:web/console;
}
```
  → Rustコードから console::log("hello, world") を呼び出せる
ブラウザは<script type="module" src="component.wasm"></script>でコンポーネントを直接ロードし、JSなしでWeb APIバインディングを自動処理する

JavaScriptとの相互運用

Component Modelはハイブリッドアプリ構造もサポートする
- 例: 画像デコーダをWebAssemblyで書き、JSから import { Image } from "image-lib.wasm"; の形で呼び出せる
- JSはWebAssemblyコンポーネントを通常のモジュールのように import/exportして利用する

今後の展望と参加

MozillaはWebAssembly CGと協力してComponent Modelの標準化作業を進めており、Googleも検討段階にある
開発者は Jco や Wasmtime を通じて、ブラウザまたはCLIで試すことができる
このモデルが定着すれば、WebAssemblyは**「パワーユーザー向け機能」から一般の開発者も活用できるWeb技術**へと拡張される可能性がある

4件のコメント

jeeeyul 2026-03-12

これは単なるMozilla的な希望的観測に近いでしょう。フロントエンドは市場の反応という辺縁系から構造的に抜け出すことができません。WebAssemblyの登場と同時に Doom 3 が移植されましたよね。DOM は現代のブラウザではすでに軽量なプロキシオブジェクトに変わって久しく、現代 CPU の JavaScript 専用命令セットや、シングルコアの量子的な限界を考えれば、このようなアプローチが市場価値の面で優位に立つことは永遠にないでしょう.

Electron の中で動く WebAssembly バイナリに何の意味があるのでしょうか。これは単なる別の GitKraken CLI、あるいは Rust 移植の名声狙いのように見えます。

carnoxen 2026-03-14

他はともかく、<script type="module" src="/module.wasm"></script>のように wasm モジュールをファイルとして挿入する方式は興味をそそられますね