OdinMonkeyの黄昏：asm.jsに別れを告げて

Mozillaは、Firefox 148からSpiderMonkeyエンジン内でのasm.js最適化の廃止（sunsetting）を正式に発表しました。asm.jsコードは標準的なJavaScriptとして引き続き実行されますが、かつてネイティブに近い速度を実現していた特化した最適化は、デフォルトで無効化され、最終的には完全に削除される予定です。

この動きは、巧妙なハックから正式なWeb標準への最終的な移行を意味しています。レガシーなサイトを維持している開発者にとって、機能面での移行はシームレスですが、パフォーマンス最適化の喪失は、高パフォーマンスなWebアプリケーションにとってWebAssembly (Wasm) への再コンパイルが唯一の実行可能な道であることを示しています。

asm.jsの遺産

2013年に導入され、Firefox 22でリリースされたasm.jsは、ネイティブ速度のコードをWeb上で実行するという課題に対するMozillaの戦略的な回答でした。当時、業界はGoogleのNative Client (NaCl) のような独自のプラグインや個別のサンドボックスに頼ることなく、いかにして高パフォーマンスな実行を実現するかという問題に取り組んでいました。

asm.jsは、素晴らしいアプローチを取りました。それは、JavaScriptの厳格で静的に型付けされたサブセットを定義することでした。これらのルールに従うことで、開発者はJavaScriptエンジンが即座に認識し、ネイティブなマシンコードに直接コンパイルできるコードを書くことができました。これにより、いくつかの画期的な成果がもたらされました：

メインストリームへの移植: UnityやUnreal Engineのような大規模なC/C++コードベースをブラウザへ移植することに初めて成功しました。
迅速なプロトタイピング: Epic Citadelのデモがわずか4日間でWebに移植されたことは有名であり、Webがゲーミングプラットフォームとしての可能性を持っていることを証明しました。
Wasmへの基盤: 最も重要なことに、asm.jsはWebAssemblyの概念実証（proof-of-concept）として機能しました。静的に型付けされたバイナリ形式がブラウザ内で効率的に実行できることを示すことで、正式なWasm標準への道を開きました。

なぜ今、移行が進むのか

WebAssemblyの普及に伴い、asm.jsのために並行した最適化パスを維持する必要性が減少しました。Mozillaは、この削除の主な理由として2つの点を挙げています：

メンテナンスのオーバーヘッド: Wasmと並行してasm.jsのパイプラインを維持するには、多大なエンジニアリングの労力が必要です。
セキュリティ: 仮想マシン (VM) 内のコード量を減らすことで、攻撃対象領域（attack surface）を減らし、ブラウザのセキュリティを向上させます。

Mozillaの内部的な命名規則は、この移行に詩的な響きを与えています。asm.jsコンパイラであるOdinMonkeyは、その「Ragnarök」（北欧神話の終末）を迎えています。その代わりに、BaldrMonkey（最適化Wasmコンパイラ）とRabaldrMonkey（ベースラインWasmコンパイラ）が、次世代のWebパフォーマンスを牽引していくことになります。

コミュニティの視点とトレードオフ

公式発表は成功物語として構成されていますが、開発者コミュニティは、asm.jsとWebAssemblyの間にあるいくつかの微妙なニュアンスを含んだトレードオフを指摘しています。

「隔離」の問題

一部の開発者は、WasmのJavaScript環境からの厳格な隔離は諸刃の剣であると主張しています。Wasmはshim（シム）なしではWeb APIを直接呼び出すことができず、JSとWasm間のゼロコピー・バッファの扱いに苦労するため、asm.jsのアプローチの方が柔軟であると感じる人もいます。

"I personally think this is a mistake... wasm is too isolated from javascript... You cant call most web apis from wasm."

パフォーマンスの境界事例

Wasmは一般的に高速で、より小さなバイナリを生成しますが、一部の開発者は、SHA256ハッシュ計算のような特定の、高度に最適化されたタスクにおいては、asm.jsの実装が依然としてWasmのソリューションよりも優れたパフォーマンスを発揮する場合があると主張しています。

実世界の例：Figmaの事例

業界の事例は、asm.jsがプロフェッショナルなWebツール進化の過程で果たした重要な役割をillustrate（例示）しています。例えば、Figmaは、もともとC++コードベースで始まりました。Asm.jsは、プロフェッショナルなデザインツールがブラウザで動作することを証明した鍵となる技術でした。Figmaは、有料顧客層を確立した後、WebAssemblyに移行しました。WasmはJavaScriptのAbstract Syntax Tree (AST) へのパース解析によるオーバーヘッドを回避できるため、Figmaはロード時間を大幅に改善しました。

結論

OdinMonkeyの廃止は、単なるレガシーコードの削除ではありません。それは、asm.jsの実験が成功したことを認めることでもあります。Webがネイティブ速度の実行をハンドルできることを証明することで、asm.jsはブラウザの進化を強制し、「Webアプリ」の定義を拡張しました。一部の人は、直接的なAPIアクセスやサブセット-JSアプローチの柔軟性を惜しむかもしれませんが、業界の標準化されたバイナリ形式への移行は、より安全で、高性能で、普遍的なWebを実現します。