• http://journal.mycom.co.jp/news/2009/02/10/070/index.html

この記事でaptana Jaxerを知りました。

サーバサイドをJavaScriptで書けるWebアプリケーションサーバです。同種のソフトのHelmaは知っていましたが、他にもあったんですね(しかも開発から既に3年も経っているようです)。

今どきのWebアプリ開発では、クライアントサイドのJavaScriptから逃れられません。他の人は知りませんが、複数言語の切替え時の(脳の)コンテキストスイッチがバカになりません。

RailsのActionView::Helpers::PrototypeHelperクラスにRubyのコードでJavaScriptのコードを書けるメソッドがあります(prototype.js前提)。たとえば、erbファイル(Javaでのjspファイル相当)に次のように書いておくと

periodically_call_remote(:url => { :action => 'index' }, :update => 'list')

生成されるHTMLファイル内で次のようになります。

new PeriodicalExecuter(function() {new Ajax.Updater('list', '/appname/index',
      {asynchronous:true, evalScripts:true})}, 10)

100歩譲って作った気持ちはわからなくも無いですが、初見の印象は気持ち悪い、でした。今でも、これを使う人間の気持ちがまったく理解できません。すべてのJavaScriptのコードをerbファイルから無くせるなら価値があるかもしれませんが、そんなことは無理です。もしできたとしたら、それは変てこなラッパー言語ができあがっているだけです。

今、Javaで書いているWebアプリをJavaScriptで書くと失う利点が色々ありそうですが、Ruby、Perl、PythonのようなLLで書いているコードをJavaScriptで書くことで失われるものはほとんど無い気がします。ノウハウの不足やパフォーマンスへの懸念ぐらいかもしれません。皮肉なことに、この反論はJavaがLLに対して行う論拠そのものです。

サーバサイドをJavaScriptで書くことは、サーバサイドの言語をただ変えるだけ以上に意味がある気がします。サーバサイドの言語をJavaからLLにすることを大げさにあおりたてる風潮がありましたが、技術的な面で見れば、騒ぐほどの違いではありません。

サーバサイドをJavaScriptで書くと、上のコードでURLを意識していた部分(/appname/index)にサーバサイドの関数名を直接書けるようになります。内部的にはXHRによるAJAX処理になりますが、プログラマから見れば完全にRPCです。少なくとも、現在主流のURLを意識したAjaxコードより、ずっと素直なRPCのプログラミングが可能になります。ソケットを知らなくてもRPCプログラミングができる(これ自体は別に悪くない)のと同様、URLを知らないWebアプリプログラマが現れても不思議はありません。

気になるのがパフォーマンスです。

• http://www.aptana.com/jaxer/benchmarks

こんな簡単なLoop処理で差がでるのが不思議です。Rubyが遅いのはintの上限チェックが入っているからでしょうか。JSON処理が意外に速くないのは面白いです。IO処理はJaxerが遅いですが、文字コード変換のためと書いてあります。どちらにせよ、IO処理はどの言語使っても、最後はCで書かれた処理に行くだけなので、どうでもよい比較です。同様の理由でDB処理の速度差の比較も意味が無い気がします。しかし、差が生じること自体は興味深いです。最後のScrapeの比較は文字列処理の速度比較で、現実的には、これが一番重要な指標です。計測したのはDOM処理の速度比較のようです。公平な評価になっているのかは不明ですが(壊れたHTMLも受けいれるDOMパーサと不正なXMLを受けつけないDOMパーサではだいぶ違うので)、JavaScriptの意外な速さに驚きます。