5月20日、Ryan Hunt氏が「Saying goodbye to asm.js」と題した記事を公開した。この記事では、MozillaがFirefox 148でasm.js最適化をデフォルト無効化し、将来的に完全削除する計画について詳しく紹介されている。以下に、その内容を紹介する。

Web技術史の一つの終焉

Firefox 148からSpiderMonkeyのasm.js最適化がデフォルトで無効になり、Mozillaは将来のリリースでコードを完全に削除する予定だ。

asm.jsを使用しているサイトを運営している場合でも、何も壊れることはない。asm.jsは単純にJavaScriptのサブセットなので、コードは通常のJITを通じて他のスクリプトと同様に動作し続ける。ただし、WebAssemblyに再コンパイルすることで、より高速な実行とより小さなバイナリサイズを実現できる。

asm.jsの歴史的意味

asm.jsは、NaClとPNaClが提起した「Webでネイティブ速度のコードを実行するにはどうすればよいか？」という問いに対するMozillaの答えだった。

そのアイデアは巧妙なものだった。エンジンがその場で認識し、ネイティブコードにコンパイルできるような、厳密で静的型付けのJavaScriptサブセットを選択することで、NaCl/PNaClと同様のパフォーマンスを実現しながら、コードをWebコンテンツ内に配置し、Web APIを使用できるようにした（独立したサンドボックス、IPC、代替APIは不要）。

asm.jsは2013年のFirefox 22でリリースされ、成功を収めた。UnityやUnrealなどのプロジェクトが、標準的なWeb技術のみを使用してC/C++コードベースを初めてWebに移植することを可能にした。Epic Citadelデモは、わずか4日間でWebに移植された。これは画期的な成果であり、元asm.jsチームにとって素晴らしい思い出となった。

asm.jsは、Web技術のみを使用してWebでほぼネイティブ速度でコードを実行できることを証明した。これがWebAssemblyへの道を開き、数年後のFirefox 52でリリースされることとなった。記事では「asm.jsがなければ、おそらくWebAssemblyは存在しなかっただろう」と述べられている。

終了の理由

では、なぜ今無効化するのか？WebAssemblyが成功し、asm.jsの利用者の大部分がWebAssemblyに移行したからだ。WebAssemblyと並行してasm.jsのパスを維持することは、メンテナンス時間のコストとなり、VM内で追加の攻撃面を提供することになる。

asm.jsコンテンツを配信している場合は、WebAssemblyへの再コンパイルを検討するべきだ。WebAssemblyパイプラインはasm.jsよりもはるかに進歩しており、より高速な実行とより小さなバイナリサイズが期待できる。

OdinMonkeyの黄昏

記事の終盤では、ユニークな北欧神話の比喩が使われている。asm.jsコンパイラはOdinMonkeyと呼ばれており、長い間予告されていたように、OdinMonkeyは運命的な終末を迎えなければならない。「Ragnarök」（ラグナロク）と名付けられたバグが「OdinMonkeyの黄昏」を追跡している。

しかし、すべてが失われるわけではない。OdinMonkeyから生まれたのがBaldrMonkey（WebAssembly最適化コンパイラ）だ。OdinMonkeyは狼フェンリルに飲み込まれるかもしれないが、BaldrMonkeyはRabaldrMonkey（WebAssemblyベースラインコンパイラ）と共に再生された世界を統治するだろう。

水曜日（Odin's day）のこの日、Mozillaは13年間のサービスを提供してくれたOdinMonkeyに感謝を表している。

詳細はSaying goodbye to asm.jsを参照していただきたい。