技術の中にはあまりにもユニークで異色のものがあり、そもそもなぜそのような技術が存在するのかと疑問に思うことが時々ある。セグウェイはその一例であり、RubyからJavaScriptにアクセスするRuby's Johnsonライブラリ(リンク)もまたしかり。このライブラリを理解しようと、シアトルにいるJohnsonの作者兼開発リーダーのJohn Barnette氏とオンラインでチャットした。
しかし、チャットの内容を話す前に、このトピックの背景を見てみよう。AJAXがWebサイト上でデスクトップアプリケーションのように機能したり、私たちがWeb2.0と呼ぶような働きをしたりするには、DOM、XMLHTTPRequestオブジェクト、必要な能力を備えたJavaScriptの可用性に何よりも依存する。しかしこれまでのところ、クライアント側のJavaScriptとサーバー上のRubyに橋渡しを構築する必要があると感じた開発者はほとんどいなかった。Johnsonはそうした橋渡しのプロジェクトであり、完全にオープンソースで、非常に興味深い実用法がある。
けれども、Johnsonの目的は舞台裏に光をあて、AJAXの自動化テストを可能にすることである。Barnette氏の考えは以下のとおりである。
Johnsonを作った理由は2つあります。まず、高度に動的なWebサイトとインタラクトしたい人々から、Aaron Patterson（Mechanizeの作者 (リンク)）宛てに届くリクエストがどんどん増えたため、Mechanizeには可能な限りサーバー側のブラウザのような動作をして欲しいというのが私たちの希望となり、それには動的なページ動作やDOMの取り扱いも含まれており、Johnsonはその機能性に到達するための足がかりとなるものだったからです。2番目はマニアックな願望ですが、2言語間でいかにスムーズにオブジェクトやメタファーを移動できるかを確かめたかったからです。
しかしJohnsonはMechanizeのようなただのスクリーンスクレイピング・ユーティリティではなく、ブラウザのようなコンポーネントだが、裏に本当のブラウザがあるわけではない。Johnsonを使うことにより多数のブラウザにまたがったテストと、テストの自動化が可能になる。この件について、Barnette氏の意見はこうである。
私にとっては、たとえばautotestのようなRubyの既存ツールを使ってテストするのと同じように、JavaScriptで高速なテストサイクルを可能にすることの方が大切です。たとえ変更が非常に小さくとも、多数のブラウザにまたがった動作検証テストが必要な場合には、JavaScriptフレームワークの記述は面倒です。Johnsonを使えば、実際のブラウザのオーバーヘッド無しにテストを実行できます。
もちろん、Johonsonのようなツールがあるだけでは不十分で、やがては実際のブラウザテストが必要になるが、自動化された反復テストの大部分をほとんど何の労力もかけずに処理できる。
Aaron Peterson氏が強調したJohnsonのもう1つのユニークな能力が、同一ソース（EJS＝Embedded JavaScript）上にRubyとJavaScriptのコードを実際に混在させることである(リンク)。非常に特異な機能性であるため、なぜこのような機能を持たせたのか、Barnette氏に尋ねた。氏の考え方は次のとおり。
EJSは非常に優れた言語生成テストでしたが、EJSを思いついたのは本気で取り組みたかったからではなく、「概念の証明」をしたかったからです。Johnsonを使ってJavaScriptでビューを書くことはしませんが、今ではおそらく十分な機能性が揃っており、Jaxer(リンク)のようなことができるのではないかと思います。
そういうわけで、EJSがJohnsonの目的ではなかったことが分かったが、その方向にフォークできたわけであるし、実際にここ［フォークするGitHubのリンク(リンク)］ですでにフォークされている。
Jaxerに馴染みのない方々のために申し上げるが、Jaxerはクライアント上とサーバー上でJavaScriptが実際に動く開発者環境である。Barnette氏はJaxerプロジェクトに大いに敬意を払ってはいるが、以下のように述べている。
Jaxerはとても大がかりです。コードの奥深くまで調べてはいませんが、Mozillaのすべて、つまりDOM、SpiderMonkeyなどのすべてをサーバー側に埋め込んでいるようです。とてもすばらしいとは思いますが、クライアント側のエクスペリエンスが豊富な方々が、サーバー側に優れたアプリケーションを書く上で必ずしも役立つとは思いません。人々が障壁と感じるものは一般に、言語ではなく概念の周りに存在するからです。クライアントとサーバーの両側でJavaScriptを使っているという事実はすばらしいですが、それによって自動的にサーバー側のプログラミングが易しくなるわけではありません。
Barnette氏の見解では、仕事を済ませられるか否かよりも、JavaScriptが言語としてどこまで行けるかということの方が問われていることが問題なのである。GoogleがChrome向けに作成したJust In Timeコンパイラのように、JavaScriptに見られる最近の進化は、JavaScriptには制約があっても多くの可能性がある証明となっている。しかし、サーバープログラミングはまだJavaScriptではきわめて初期の段階にある。JavaScriptの弱点の1つとして、強力な汎用の標準ライブラリが欠如していることが挙げられ、競合するフレームワークが勢揃いしていても、その全てが標準のレベルに達しているわけではない、というのがBarnette氏の意見である。
Chromeがテーマに上ると、氏がすばらしいニュースを教えてくれた。
Johnsonは今のところSpiderMonkeyに依存していますが、パブリックAPIはランタイム・アグノスティック（ランタイムに依存しないこと）なので触れておく価値があるでしょう。メンバーの1人（オーストラリアのMatthew Draperで、尊敬されています）がV8のブリッジに取り組んでおり、私たちも埋め込みできるほどJavaScriptCore/SquirrelfishのパブリックAPIの機能性が十分であるかどうか、確認できればと思っています。スイッチを入れ換えるだけで、多数のランタイム上のコードをテストできるようにしたい、というのが心からの望みです。
それまでの間、Ruby on Railsを一方に、そしてもう片方にはJavaScriptというように、サーバー言語を分離しておくことが最良の選択のようである。言語と手元にあるタスク向けに最適化したハイブリッドである。Johnsonでは以下が可能になるので、この点に関して非常に価値がある。
JavaScript用のより優れたサーバー側ライブラリ/標準ライブラリのプロトタイプをブラウザの外で作成可能にします。透過的にRubyにブリッジ可能なら、JS.File APIのプロトタイプ作成は、CやC++、ましてJavaでネイティブの実装を記述することと比較したら、大いに簡単になります。
もう１つの懸案事項は、開発ショップで日々いかにJohnsonを使うかである。Barnette氏の意見では、AJAXの機能性を対象とした、継続的な統合テストとオートテストセッションに理想的である。
プログラムやスクリプトができるMechanizeのように動作するツールはまだ準備されていないが、やがて開発される可能性はある。それまでの間、チームはサーバー側の実行可能なDOM実装の提供に全力を注いでいる。複数のオプションを遂行中である。好材料はソリューションが見つかりそうなことである。Barnette氏はこの件について次のように意見を述べている。
そのことに関しては、2つの方法を進めています。env.jsのJohn Resigと協力して取り組んでいますが、env.jsはXML/HTMLパーシングやスレッディング、ネットワーク要求に使われる、ランタイム特異的な割り当てを最低限にとどめながら、DOMのJS実装を提供することを目指しています。libxmlのHTMLパーサーを使うソリューションも考察中なので、おそらくlibxmlベースのソリューションに行き着くのではないかと思います。
自動化とAJAXがもたらす価値を理解する能力という話題について言えば、Firebugのコンソールと一体化するツールとしてFirePHP(リンク)がある。Johnsonを使ってこれに似たものをRubyの世界に実装できないか尋ねると、Barnette氏は次のように述べた。
おお、すてきですね。Railsのプラグインとしてかなり簡単にそれができるくらいのところまで、Johnsonは来ていると思います。メンバーの誰かが書くべきですね！
プロジェクトとしてのJohnsonの長所はこれまで述べたことのほかに、チームの質の高さがある。Barnette氏以外に、Yehuda Katz、Aaron Peterson、Matthew Draperの各氏が名を連ねる。
Yehuda、Matthew、Aaron、そして私も、みなそれぞれ単独で、JavaScript向けの実行可能なRubyバインディングに取り組んでいました。お互いの取り組みが分かると、徹底的な討論を経て、合流しました。Johnson内でjQueryのテストスイートを立ち上げ、動作させることに尽力しているYehudaは、高速ブラウザを、より少ないテストとプロトタイプで手に入れたいのです。Aaronが最も興味を持っているのはページの自動化であり、Matthewはというと、サーバー上でJSランタイムを使い、プロダクションアプリケーションを実際に動作させていることが多いので、確かな堅牢性をもたらすことに興味を持っているのでしょう。
最後になるが、将来についてと、Johnson 1.0がもたらす予定のものについて尋ねたところ、Barnette氏はこう語った。
ブラウザなしで実行可能なDOMを提供できるようにすること、これは1.0で絶対にはずせません！
原文はこちらです：http://www.infoq.com/news/2008/10/johnson-javascript-on-ruby