ExtJSのクリエータ、Jack Slocumが今回のリリース2.0について語る

• テーブルのグループ化とサマリー
• スクロールするタブ
• アンカーレイアウト
•  列（コラム）表示のTree Widget（ツリーウィジェット）
•  Webデスクトップ
• 新しいAPI Documentation Center（ドキュメンテーションセンター）
• 新しいサンプル

 ExtJS 2.0のAPIは安定化が済んでおり、4、5社の顧客が本番環境で使用中である。このフレームワークは、LGPL 3.0、商業ベース、OEMでライセンスされている。最終バージョンは10月31日頃を目標としている。

InfoQはExtJSのクリエータJack Slocum氏に今回のリリースについて話を聞いた。

 jQueryやDojo、Prototype、YUIなどのJavaScriptエコシステムとの関連で、ExtJSを説明してください。JavaScriptのフレームワークを層にして使う時代に向かっているのでしょうか。さらに、jQueryやYUI、PrototypeでなぜExtJSが必要なのでしょうか。（オプションの）ExtJSだけでは足りないのでしょうか。

jQueryやPrototype、YUIは本来、JavaScriptのコアライブラリです。YUI、そしてもっと最近ではjQueryには一緒に使うウィジェット・コレクションがありますが、真に統合型と呼べる完全なアプリケーション開発プラットフォームは提供していません。コアライブラリはすばらしいのですが、アプリケーション開発となると、デベロッパーが埋めなければならない穴がまだ多数存在し、Extはそのギャップを埋める手助けをします。Extに似た統合アプリケーション・プラットフォームの提供を試みているものとしては、Dojoが唯一の主要オープンソース・フレームワークです。Dojoはすばらしいツールキットですが、アプリケーション開発ではExtの方がよりまとまりのあるフレームワークであると思っています。Extコンポーネントは他のExtコンポーネントと連携するようデザインされているため、共同使用するプロセスがシームレスになります。このような種類の相互通用性は、結束の強いチームが同じ目標を念頭に設計と開発を行っている場合に限り達成されるものであり、オープンソース・プロジェクトでは通常見られません。私たちはプレゼンテーション、パフォーマンス、相互通用性、拡張性を考慮しながら、全コンポーネントをゼロから構築しており、それは見てわかると思います。

 Extは間違いなく独立型フレームワークとして使用できます。実際、他に必要条件が何もなければ、独立型として使用するのが好ましく、その理由は、最小のファイルフットプリントで、最も緊密なサポートと統合が利用できるからです。しかし、DOMなどのコアサービスやイベント処理、Ajax接続性およびアニメーションのベースライブラリとしてのjQuery、YUI、Prototypeと一体化する能力も提供しています。そうした一体化を選ぶ理由の一つは、Extがネイティブでは提供しない、ライブラリ独特の既存ウィジェットを使わなければならないときです。YUIのhistory control（ヒストリ制御）がうってつけの例でしょう。history controlを使うには、YUIのベースライブラリが必要になるので、Extはベースライブラリの依存性を利用することにより、Ext自体にはそのベース機能の複製を追加することはありません。したがって、アプリケーション全体のフットプリントが最小になります。このアプローチを使う別の理由は、すでに他のライブラリを基にしている既存アプリケーションに漸次Extを追加していきたい場合です。ここでも、代わりのライブラリがすでに利用可能であるなら、Extはそのライブラリを利用できます。私たちがやっていることは、デベロッパーに選択肢を与え、パフォーマンスを最適化することに尽きます。実際、誰でも他のフレームワーク用のアダプタを追加することもできます。ベースライブラリ・アダプタ・インタフェースを実装することにより、Dojo 、Ajax.NET、Moo、その他あらゆるJavaScriptライブラリをExtのベースとして簡単に活用できるのです！

多種多様なJSライブラリをサポートする上で最も難しいことは何ですか。

最も難しい問題はおそらく最も明白なことでしょう。つまり、他のライブラリを最新に保ち、Extとうまく連動させることです。それぞれのライブラリに新バージョンが出ると、私たちもそれをテストして、Extデベロッパーにとって都合の悪い変更がなされていないか確かめなければなりません。

同様に、さまざまなWebブラウザをサポートする上で一番の苦労や問題は何ですか。

 フレームワークへの変更や追加をテストし、実証するために要する時間が事実上一番の問題です。異なるブラウザやブラウザのバージョンだけでなく、各ブラウザ上のさまざまなdocタイプもサポートしなければならないのですから。

 Extの優れた点のひとつに、フレームワークそのものに直接多数のツールを組み込んで、ブラウザ間の問題を処理していることがあります。これには、透過的にボックスモデルの問題を基準化するためのベースコンポーネントクラスに加え、CSSのハックを使わずにブラウザの不具合を何とかするためのプラットフォーム独自の固定情報やCSSクラスの自動適用が含まれます。このサポートが直に組み込まれ、コアフレームワークが安定し、かつ繰り返しテスト済なので、エンドデベロッパーはたいてい、ブラウザ間の問題をそれほど心配せずに開発できます。そのため、開発がスピードアップし、アプリケーション側のテストを大幅に削減できるのです。

ExtJS 2.0の魅力を定義しなければならないとしたら、それは何でしょうか。

デベロッパーの生産性と、構築していく上で基礎となる確固として矛盾のない土台です。Extのバージョン1.xは足場としてはすばらしいライブラリでしたが、簡略化が可能な領域や、デベロッパーの専門知識やコードをさらに不要にできる領域が判明したのです。遅延レンダリングやコンポーネント・ライフサイクルなど、複雑なアプリケーション構築時のより難しい問題に私たちが取り組み、デベロッパー自らが処理する必要がないようにしたいのです。2.0のもうひとつの主要改善部分は、コンポーネント（プラグイン）のカスタマイズ、コンポーネント（コンテナ）のグループ化、コンポーネントの初期化用として、より頑丈な基礎が用意されていることです。レイアウトとコンポーネント全体にこれまでにない一貫性があるということは、Extでコンポーネント一つの設定と取り扱いをひとたび理解すれば、フレームワーク内の全コンポーネントを同じように扱えるわけです。エンドユーザーにしてみれば、迅速かつ楽な開発につながり、同時に、Extの大きさやパフォーマンスで犠牲にしているものは何もないのです。

あなたの意見では、2.0で最も革新的な機能は何ですか。

 おそらく、新しいコンテナ・アーキテクチャでしょう。1.0では、アプリケーション・レイアウトは主にBorderLayout（レイアウト用）とBasicDialog（アプリケーションのダイアログとウィンドウ）に焦点を当てていました。こうしたコンポーネントは見栄えが良く、極めて機能的でしたが、コードを再利用して組み込み機能を拡張しようとすると限界がありました。新しいコンテナとレイアウト・アーキテクチャを使い、2.0ではかなりたくさんのレイアウト・マネジャーを追加し（CardLayout、ColumnLayout、FormLayout、TableLayoutなど、全９種）、コンテナAPIを統合したので、コンポーネントを追加しているのがTabPanelであろうが、WindowやPanelなどであろうが、APIはいつも同じです。結局、私たちは単にウィジェットを提供しているのではなく、ユーザーのアプリケーションとうまく連動し、アプリケーションとともに発展する土台を持った統合型フレームワークを提供しているのです。

SilverlightやFlexなどの技術よりも、クライアント・アプリケーションにExtJSとJavaScriptを使用する論拠をどう考えますか。

ある意味、Extは新しいプラグインベースの技術を実際に補完するものなのです。FlexとSilverlightは両方とも機能の一部としてDHTML/Ajax開発をサポートしていますが、そのとおりのシナリオでExtがうまく働くという完璧な見本がAdobe AIR Simple Tasksデモアプリケーション(source)なのです。AIRでは、延々と時間を費やして独自のウィジェットラッパーとカスタムCSSを記述しない限り、ネイティブには達成できないルック＆フィールを、Extはそのデモの中で実際に提供しているのです！

もちろん、ネイティブプラットフォームには、ネイティブコンパイレーションやより良いツールサポートなど、JavaScriptには現在ない、固有の利点があります。しかし、JavaScriptベースのアプリケーションのより単純な開発や、より単純な開発モデルが必要とされる余地は、おそらく常に存在するでしょう。プラグインが要求されるときはいつも、開発やデプロイメント、メンテナンスの面で複雑性が増すのです。マイクロソフトはSMS、Active Directory（アクティブディレクトリ）、その他多数の頭痛の種に関する「Enterprise Sliverlight Deployment Guide」（エンタープライズSilverlightデプロイメントガイド）を発行しています。JavaScriptアプリケーションでは金輪際必要のないものです！　さらに、JavaScript/DHTMLのサポート（こちらの方がプラグインのサポートより実際ずっと好都合なのです）が大いに改善されている最近のモバイルプラットフォーム（例えばiPhone）を見れば、プラグインよりJavaScriptを選択する非常に良い理由がまだ見つかるのではないでしょうか。

重要なのは、利用できるツールがたくさんあり、目の前の仕事に最適なツールをデベロッパーが選ぶべきだということです。それがプラグインベースの技術のこともあるでしょう。しかし、JavaScriptベースの技術がWeb開発ツールボックスの中にしばらくは居場所を維持し続けることを確信していますし、良い位置づけにあるExtは重要な役割を果たすでしょう。

ExtJSの次の予定は何ですか?

現在のところは、信頼のできる安定した2.0のリリースに焦点を当てています。最初のリリースはアルファ版ですが、2.0のコードベースはすでにかなり多数のデベロッパーに2, 3カ月ほど使ってもらっており、幸先の良いスタートとなっています。