Jaxerを知りました。サーバサイドをJavaScriptで書けるWebアプリケーションサーバです。同種のソフトのHelmaは知っていましたが、他にもあったんですね(しかも開発から既に3年も経っているようです)。今どきのWebアプリ開発では、クライアントサイドのJavaScriptから逃れられません。他の人は知りませんが、複数言語の切替え時の(脳の)コンテキストスイッチがバカになりません。RailsのActionView::Helpers::PrototypeHelperクラスにRubyのコードでJavaScriptのコードを書けるメソッドがあります(prototype.js前提)。'list')生成されるHTMLファイル内で次のようになります。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の意外な速さに驚きます。04:17JavaのRhino使っていると思っていましたが、C/C++で書かれていました(JavaScriptエンジンはMozillaのSpiderMonkey)。ソースコードのtar.gzのサイズが58MBって...と思ったら、Mozillaのソースコードが全部入っていました。サーバサイドをJavaScriptで書くと、上のコードでURLを意識していた部分(/appname/index)にサーバサイドの関数名を直接書けるようになります。内部的にはXHRによるAJAX処理になりますが、プログラマから見れば完全にRPCです。少なくとも、現在主流のURLを意識したAjaxコードより、ずっと素直なRPCのプログラミングが可能になります。ソケットを知らなくてもRPCプログラミングができる(これ自体は別に悪くない)のと同様、URLを知らないWebアプリプログラマが現れても不思議はありません。言っている意味がわかりません。スクリプトやLLを持ち出さなくてもURLに関数名を書くことはできるはずです。23:50どのレベルのツッコミをしているか不明ですが、想像して書きます。XHR(XMLHttpRequest)でリクエストを投げるURLに、(サーバ側の)関数名を書けるという話をしているなら、近い話をしていますサーバ側のフレームワーク(Railsなど)が、URLと関数名の対応を適切に行ってくれると(まあまあ)透過的に見えているだけです。関数に渡すパラメータなどはHTTPを意識(クエリーパラメータにシリアライズ化)します。サーバ側をJavaScriptで書くと、次のようなことが可能かもしれない、という趣旨で書いています。javascript)と呼びます。ejs内に書いたjavascriptのコードは基本的にサーバ側のレスポンス時に評価されます(JSP内に書いたJavaコードと同じ動作です)。ejs内にDOMのイベントハンドラを書いたとします。このJavaScriptコードはstubコードの呼び出しに変換されて、レスポンス内に残ります。Webブラウザ上で、そのDOMイベントが起きると、stubコードを通じてXHRでサーバにリクエストします。このリクエストはサーバ側のJavaScript関数を呼びます。12:26あ、ちゃんと元記事読んで無かったです。サーバーサイドにJavaScriptの処理系を置くという構想があるってことですね。