中間言語としてのJavaScriptはどうなったのか

LLVM

なぜか３年前の記事が急にブックマークされていたのでフォローする記事。
↑の記事の1年後、InfoQの記事( http://www.infoq.com/news/2009/09/javascript-compilation-target )でいくつかのJavaScriptにコンパイルする言語が紹介された。もちろん、GoogleのGWT(Google Web Toolkit)もJavaScriptを出力するJava環境と言える。
先の記事で触れたエミュレータでの活用は、見たところDirect-threadingによるものに限られているように見える。つまり、CPU命令をJavaScript的なfunctionとして実装し、CPU命令と１対１対応させる。Google V8のような、Direct-threadingスタイルのJITCはこのような手法でも十分な性能を得られる。
ここ３年の動きでもっとも重要なものはEmscriptenや、他の同様なプロジェクトだろう。EmscriptenはLLVM→JavaScriptコンバータで、CPythonが動作する程度の互換性を持っている。

Emscriptenのパフォーマンスは、当時の懸念を十分に払拭するものと言える(それでも実際のCプログラムよりは20倍以上遅いが。。)
実際の応用という観点ではあまり目覚しいものはなかった。Node.jsのようにJavaScript自体を活用する方向は十分に流行しているように思えるが、肝心のライブラリ機構(JSANやCommonJS)はあまり流行せず、独自のパッケージモデル(npm)になった。

３年で何が変わったのか

IntelのLarrabeeやIBM/Toshiba/SonyのCellは一般に普及しなかった。このため、JavaScript JITCがこれらのアーキテクチャが備える高度なSIMD機能を活用する可能性も低くなり、より"大きな粒度"で演算を抽象化しなければパフォーマンスを発揮できないことになった。
演算性能が重要なアプリケーションはWebGLのようなJavaScriptの"外"で実現される仕組みに今後は依存することになるだろう。

  • モバイルクライアント上でのWebアプリケーションが(政治的に)流行しなかった

携帯電話やタブレット端末上のアプリケーションはWebアプリケーションではなくネイティブアプリケーションに依ることが主流となった。当初iPhoneアプリケーションはWebアプリケーションだったが、すぐ(2008/6)にネイティブアプリケーションが解禁され、決定的な流れになった。

当時の記事で想定していたのは、"ブラウザの中にブラウザを実装する"といった柔軟なレンダリングに対する要求が今後高度化するという点だった。しかし、実際にはそのような事は起こらず、HTML5で出来ることを重視する方向となった。
一番考え易いのは、GoogleのNative Clientが今後流行するか?というポイントだろう。Native Clientの目的は高度にインタラクティブなWebページを実現することと、既存のCコードの流用だが、前者はJavaScript JITCの高度化やWebGLですでに実現されつつある。後者のポイントがアピールする領域が実はあまり大きくないことは考慮に値するだろう。
(例えば、NaTclを使いたい人がどれほど居るだろうか　http://slashdot.jp/developers/article.pl?sid=11/04/15/181223 )

JavaScript出力の政治的重要性

それでも、JavaScriptを出力することは政治的に重要でありつづけている。

  • 多くのプレイヤにとって、Google Native Clientの流行は避けなければならない。

Chromeでしか機能しないNaClはベンダロックイン機構として機能する。もっとも、FirefoxはPepper Plugin APIのサポートによってNative Clientを獲得するかもしれない。他のブラウザは特に動きはない。
歴史的には、プラグインAPIが統一されていたのは非常に短い期間でしかない。IEは登場当初はNetscapeのプラグインAPIをサポートしていたが、ActiveXへの置き換えによってサポートを打ち切った。ブラウザ間の互換性という観点から言うと、JavaScript API以外にさらにAPIを作るのはあまり良いことには思えない。
C言語からJavaScriptへの変換が十分に実用的ならば、Native Clientの存在する理由もあまり大きくはなくなる。もっとも、JavaScriptの実行環境自体がそのレベルに到達する可能性は殆ど無いだろう。
もちろん、ここでのNaClはFlashなりJavaにも置き換えて考えることができる。現時点で受け入れ可能で十分にオープンな言語環境はJavaScriptしか無いのが現実だろう。

  • 言語をWeb開発に組み込む手段となりうる

現状では、Web開発に使われる言語としてJavaScriptは不可欠になっている。多くのJVM言語が流行したように、今後JavaScript(に出力するタイプの)言語が流行する可能性が無いわけでは無い。
ただ、最初の記事で触れているように、一旦JVMや.netを経由することでも十分に機能する可能性は有るので、直接JavaScriptを出力するからには何らかのメリットが必要になる。

  • JavaScriptは停滞している

現状のJavaScriptも十分に機能しており、HTML5という大きな課題が前面に出ているので、しばらくJavaScriptに関して大きな進展は期待できない。
逆に言えば、現状のJavaScriptは安定しているとも言える。

今後、"JavaScriptを出力するコンパイラ"は何をすべきか

簡単に纏めると、"言語とJavaScriptのブリッジを確立する"ことに尽きる。NaTclがやったように、DOMを操作できる言語としての売り込みが重要になるため。
モデルとすべきなのはObjective-Cだろう。Objective-Cは言語ランタイムとBridgeSupportの作用で、RubyやPythonのような既存の言語から直接クラスライブラリを操作することができる。.netやOLEにも同様の機構は有る。
その言語がObjective-Cや.netのライブラリとやりとりしているのと同じレベルのサポートを最低限提供する必要がある。
(一応、JavaScriptの世界にもWebIDLがあるが、現実問題として既存の有象無象のJavaScriptライブラリとの連携なくしてWeb開発はありえないので、この問題はより難しい。)
また、いくつかの言語機能(クロージャや例外機構)をJavaScriptネイティブのものにマッピングするのも興味深いかもしれない。しかし、Scheme→JavaScriptを行ういくつかの研究では、熱心に例外機構やクロージャにマッピングするよりは、VMをJavaScriptでつくってしまったり、CPS変換してしまったほうが実際には高速に動作するとしていることもある。
パフォーマンスは前述の理由で重要な問題ではなくなってしまったが、それでもコードを常識的なサイズに収めることは要求されている。コードサイズを小さくする工夫として簡単なのは、JavaScriptの既存の言語機能を活用することだろう。。
そして、これらの特徴は言語X→Java→JavaScriptのような"多段式"の変換では得づらいものとなる。JVMや.netのような他のVMはすでにJavaScriptの実行環境を持っているので、動的言語にとってはJavaScriptは現時点でももっとも魅力のあるコンパイラターゲットだろう。