WASMをWebの第一級言語にする
JS glueなしでWeb APIを直接呼び出すComponent Model
WebAssemblyがWebで2級市民として扱われている現在の問題と、MozillaのComponent Modelがこれをどう解決しようとしているかを取り上げます。
構造ダイアグラム
Before vs After
現在: WASM = 二級市民
📝
Rust / C++
→
📦
.wasm
→
⚡
JS Glue Code
embind / wasm-bindgen
→
🌐
Web API
-45%パフォーマンス
未来: Component Model = 一級市民
📝
Rust / C++
→
🧩
Component (.wasm)
WITインターフェース含む
→
🌐
Web API直接呼び出し
JS glue不要！
WITインターフェース例
WIT宣言:
component {
import std:web/console;
}
Rustでの使用:
use std_web::console;
console::log("hello, world");
標準化タイムライン
2017 WASMリリース
→
現在: Mozilla + Google標準化中
→
実験: Jco、Wasmtime
→
未来: ブラウザネイティブサポート（数年かかる）
動作フロー
1
現在: WASMはWebAssembly.instantiateStreaming()などJS APIで手動ロードが必要
2
現在: DOM、consoleなどWeb APIに直接アクセス不可 — JS glue codeがブリッジ
3
現在: 言語ごとに別のバインディングツールが必要、rustc --target=wasmの出力がブラウザで直接動かない
4
Component Model: WIT（Interface Description Language）で必要なWeb APIを宣言
5
Component Model: ブラウザが<script type="module" src="component.wasm">で直接ロード
6
Component Model: JSからimport { fn } from "lib.wasm"形式でハイブリッド使用可能
7
結果: JS glue code完全除去 → 45%の性能オーバーヘッド解消、ツールチェーン統一
メリット
- ✓ JS glue code完全除去 — 45% DOM性能オーバーヘッド解消
- ✓ WASMをJSのように<script>タグで直接ロード可能
- ✓ 言語別ツールチェーン統一 — 標準コンパイラで直接ブラウザ実行
- ✓ WITで型安全なWeb APIインターフェース宣言
- ✓ JSとのハイブリッド使用可能 — 段階的導入可能
- ✓ ブラウザ外でも実行（Wasmtime） — webとサーバーコード再利用
デメリット
- ✗ まだ標準化進行中 — プロダクション使用は時期尚早
- ✗ 仕様変動が頻繁でツーリングのchurnが発生
- ✗ Polyfill/機能検出が困難 — JSブリッジの柔軟性を失う可能性
- ✗ Component Model自体が新しい複雑性を導入（WIT学習が必要）
- ✗ WebGL2/WebGPUではJS shimのコストは既に微小
- ✗ メモリ管理未解決 — Wasm GC提案がDOM参照維持に必要かどうか不明
ユースケース
DOM集約型WASMアプリ — glueなしで直接DOM操作
Rust/C++ webフレームワークがJSなしで独立動作
多言語コンポーネント組み合わせ — Rust画像処理 + Goネットワーク + JS UI
モバイルOS閉鎖性への代替 — ネイティブアプリレベルのwebアプリ
WASM Registryによるコンポーネント再利用エコシステム