- WebAssembly（Wasm） は今なお多様な実製品で中核技術として使われており、ゲームエンジン・デザインツール・Webコンテナ などで重要な役割を果たしている
- 言語自体は ハードウェアに効率よくマッピングされる構造 を持ち、安全性と移植性 を中心に設計されている
- セキュリティモデル は「デフォルト拒否（deny-by-default）」構造で、プロセスレベルの分離と高速な実行速度 を可能にする
- プラグインエコシステムと言語横断サポート によってさまざまな環境で活用されているが、ブラウザ全体を置き換えるほどの採用にはまだ至っていない
- 現在のWebAssemblyは ライブラリおよびランタイムレベルで深く統合 されており、標準化と機能拡張が急速に進んでいる技術である
実際の活用事例
- WebAssemblyは Godot, Figma, Stackblitz, Squoosh.app, Zellij, Ruffle などで中核機能を担っている
- GodotはWeb向けゲームビルドに、FigmaはC++コードをブラウザで実行可能な形に変換するために使用している
- StackblitzはWebコンテナ、RuffleはFlashエミュレータとしてWasmを活用している
- ただし、Web全体をWasmベースで構築した大規模サイトはまれ で、ほとんどは特定機能単位で使われている
WebAssemblyの定義と速度
- WebAssemblyは 言語（language） であり、独自の速度概念を持つのではなく エンジン性能に依存 する
- JavaScriptと同様に ランタイムエンジン（V8, SpiderMonkeyなど） が実行速度を決定する
- WebAssemblyは 現代的なハードウェアに効率よくマッピングされる構造 を持ち、コンパイル方式でもインタプリタ方式でも実行可能である
効率的なマッピング構造
- Wasmは アセンブリ言語に近いバイトコード であり、ほとんどのハードウェアに損失なくコンパイル可能である
- WAT（WebAssembly Text） はWasmのテキスト表現で、ほぼ1:1で変換できる
- JVMバイトコードに似ているが、APIが小さく安全性保証が強い
- メモリアクセスは明示的であり、ホスト環境で許可されたリソースだけを利用できる
コンパイルターゲットとしてのWasm
- Rust, C, Zig, Go, Kotlin, Java, C# など多様な言語がWasmへコンパイル可能
- Python, PHP, Ruby のようなインタプリタ言語もWasmビルドとして実行できる
- ブラウザは標準でWasmエンジンを含み、Wasmtime, WasmEdge, Wasmer などの独立ランタイムも存在する
- 単一のWasmアーティファクトは ハードウェア非依存で実行 できる
セキュリティ構造と活用
- WebAssemblyは 「deny-by-default」セキュリティモデル を採用し、外部アクセスは明示的なimportだけを許可する
- 隠蔽された制御フロースタック、線形メモリ、制限された命令セット によって強力な分離を保証する
- Cloudflare はV8 isolateを用いてWasmベースのコード実行を隔離し、Fermyon は サブミリ秒級の起動速度 を提供する
- Ruffle はFlashコンテンツを安全に復元し、Pyodide はPythonをWasmで実行し、Figma はWasmベースのQuickJSでプラグインを実行する
移植性と埋め込み
- Wasmランタイムは軽量で、Zellij, Envoy, Lapce などはプラグインシステムにWasmを採用している
- JavaScriptエンジンのある環境でも、画像処理、OCR、物理エンジン、レンダリング、メディアツールキット、データベース、パーサ など多様なWasmライブラリが使われている
- 多くの場合、ユーザーはWasmが使われていることを認識しない まま、ライブラリ内部で透過的に動作している
速度とサイズの再検討
- ブラウザはJSと同じパイプラインでWasmを実行するため、エンジン構造上の性能限界が存在 する
- 言語の型システムとコンパイラ最適化の水準 によって効率差が生じる
- ホスト・プログラム境界のコスト と バイナリサイズの増加 が欠点として指摘される
- WASI 標準がこれを緩和しようとしているが、文字列型の標準化はまだ未完成 である
- Zig は最も小さなWasmバイナリを生成する
- ネイティブ環境では スレッディング・IO・メモリ使用量 により性能低下の可能性がある
言語および標準開発の動向
- Wasmの標準化は W3Cワーキンググループ と Bytecode Alliance が並行して進めている
- 後者は WIT, Component Model などツール中心の開発を主導している
- 新機能提案が迅速に採用 されており、一部では速度や方向性をめぐる議論もある
- Wasmは JavaScriptの代替というより内部統合技術として普及 している
- Blazor, Leptos のようなフレームワークはJSを直接扱わずにWasmを活用する
- 現在のWasmは ライブラリ制作者を中心に採用 されており、一般開発者は内部動作を意識せずに利用できる
- 教材の難解さが学習障壁として指摘され、「watlings」 のような学習プロジェクトも紹介されている
1件のコメント
Hacker Newsの意見
私は Wasm が作られたときの目標の大半を達成したと思っている
個人的に数十のプロジェクトで Wasm を中核コンポーネントとして使ってきた
JS エンジンは非常に高速だが、Wasm は依然として CPU 制御のレベルが高く、性能 が卓越している
ただ、JS+HTML+CSS を完全に置き換えるという期待には届かなかった。DOM バインディングの不在が大きな理由だと思う
Yew のような Wasm フレームワークも使ってみたが、JS の上に継ぎ足したぎこちないレイヤーのように感じた
Blazor はまだ使ったことがないが、私は今でも JS で書くほうが楽だ
それでも Wasm は静かに多くの場所で動いており、それが本当の成功の証拠だと思う
たとえば ブラウザでのオーディオ速度調整 機能は、C++ ライブラリを Wasm で動かして初めて可能になるレベルの性能を出している
まともな DOM バインディングさえできれば、JS は 10 年以内にフロントエンドから押し出されるだろう
C# はバックエンドとフロントエンドでコード共有がしやすく、Razor テンプレート も IDE サポートが良い
しかし .NET CLR と BCL を丸ごと載せなければならないので、バンドルサイズが大きい
DOM アクセスが難しいため、Blazor は JS 側に小さな Virtual DOM レンダラーを置く構造になっている
性能は悪くないが、手書きの JS よりは依然として遅い
F# ベースの Bolero も興味深いが、チームを説得するのは難しい
DOM と相互作用するには、それに合った 高水準言語 が必要だ
JS はその役割をうまく果たしており、HTML/CSS/JS の組み合わせはすでに UI 開発の共通語になっている
ブラウザレンダリングを捨ててキャンバスベースに向かう試みもあるが、依然としてニッチな領域だ
単純な Web サイトですら 数 MB のランタイム をダウンロードしなければならない世界はひどい
実際の遅さの原因は JS ではなく DOM だ。結局 DOM と相互作用しなければならないのだから
私は数年間 WebAssembly で仕事をしてきて、もうすぐ Wasm ベースのフレームワークを公開する予定だ
エコシステムは急速に発展したあと急に鈍化し、WASI と Component Model の導入が混乱を招いた
エンジンごとにサポート水準が異なり、ドキュメントやコード、Issue を渡り歩かなければならない状況が多い
最大の問題は JS/TS サポートだ。現在は ハックに近い統合方式 なので安定していない
Web Containers が改善をもたらしたが、すでに多くの開発者が Bun に移ってしまった
Wasm の 潜在力 は非常に大きい
理論上はあらゆるプラットフォームの共通コンパイルターゲットになり得る
だが現実は Figma の一部機能を高速化する程度で、やや期待外れだ
委員会中心の開発体制なのでスピードが遅いのも限界だ
Native Client の時代にはネイティブ速度のアプリが可能だったのに、今の Wasm はそれより遅い
JS バインディングの構造を Wasm にも適用できたはずで、惜しい
しかも Wasm は JS より速いわけでもない
HTML/CSS/JS はすでに有用性が実証されている一方で、Wasm は依然として見慣れない技術スタックだ
Docker 中心のエコシステムが足かせになっている
JS エコシステムの多くの ビルドツール は Rust で書かれており、一部は Wasm としてブラウザで実行されている
React や npm のエコシステムも内部的に Wasm を利用している
Wasm が消えれば JS フロントエンドの世界は大きく揺らぐだろう
ただしネイティブ Wasm UI フレームワークはまだ不十分だ
DOM と CSS に依存せざるを得ず、JS を通じてブラウザ API にアクセスしなければならないので非効率だ
Rust や Kotlin で DOM を制御することはできるが、Rust はフロントエンドには低水準すぎる
モバイルクロスコンパイル はますます増えており、JetBrains Compose Multiplatform がその一例だ
Wasm の発展を妨げているのは ツール群 だ
デバッグはいまだに
printfレベルで、Chrome の DWARF プラグインも長いこと更新されていない言語ごとに .wasm ファイルを作り、import/export を設定する過程が複雑だ
GC サポートも完全ではないため、.NET のようなエコシステムは独自 GC を載せなければならない
WIT はまた別の COM/CORBA/gRPC の試みのように見える
Emscripten は複雑で不安定で、wasi-sdk は機能不足だ
LLVM もエンジンも最適化が不十分で、Rust の Wasm ツール群も事実上停止している
JS から Wasm モジュールを 標準方式で import する方法すらない
マルチスレッド対応も COOP/COEP ヘッダー設定が必要なため、GitHub Pages では不可能だ
ツール群が「技術デモ」の水準を超えていたなら、もっと広く使われていたはずだ
私たちの会社 Leaning Technologies は Wasm を積極的に使っている
WebVM でブラウザ上で x86 バイナリを実行し、
BrowserCraft で Java アプリ（Minecraft を含む）を動かし、
BrowserPod で Node.js コンテナをブラウザ上で動作させている
非常に強力だが パワーユーザー向けツール だ。一般的なフロントエンドロジックを Wasm にコンパイルするのは非効率だ
CheerpJ の進化の速さは印象的で、あと 10 年早く出ていれば Web プラットフォームは変わっていたかもしれない、という意見だ
JS が嫌いな立場からすれば、JS のない Web サイト を作れることこそが Wasm の本当の魅力だ
私は Rust ベースの Wasm フレームワーク Dioxus で働いている
フロントエンド Wasm は、コード分割、ホットリロード、デバッグシンボル、アセット統合など基本的なツール不足が問題だった
2025 年にはそれらがかなり改善され、Vite のようなツールとの統合も良くなった
AI ツールのおかげで Rust 開発の速度も上がり、今後 Wasm フレームワーク がさらに注目されると期待している
Wasm の バイナリサイズ が大きすぎるという指摘があった
DSL 環境ではダウンロードに数秒から数分かかることもある
JS はもっと小さく、ダウンロード中でも実行できるという主張だ
Rust でビルドすれば 10〜100KB 程度まで縮められる
JS はダウンロード中に実行されず、Wasm はストリーミングコンパイルでより速く起動できる
ブラウザがすでに提供している機能を重複実装することになる
たとえば FSHistory は 24KB で x86 エミュレーションを実装している
ただしネイティブのエコシステムはコードサイズ最適化に慣れていない
記事で「Wasm で作られた大規模 Web サイトはない」と言っていたのは、私の経験とは違う
Wasm プロジェクトの目標は Web アプリ全体を置き換えることではなかった
人々は誤った期待を抱き、「なぜそれが実現しなかったのか」と尋ねているように思える
私は実際に Wasm をさまざまな 実務事例 に適用してきた
バックエンドで必要な部分だけ切り出して処理できる