Dojo Toolkit(リンク)は、オープンソースのJavaScriptモジュラーライブラリで、JavaScriptやAjaxベースのアプリケーション、Webサイトを簡単にすばやく開発できるように設計されている。InfoQはSitePen最高経営責任者でDojo Toolkitの制作者のひとりであるDylan Schiemannに、AJAXやComet、Bayeux、RIA、最近リリースされたDojo Toolboxについて聞いた。
InfoQ：Dojoの開発を始めたいきさつ、当初のビジョン、そして成長したDojoが何になったのかについて、簡単に説明していただけませんか。
2004年の始め、Alex RusselがDHTML（現在のAjax）プロジェクトの協力者をInformaticaに雇い入れようと探していて、私がその協力者になったわけです。こうしたプロジェクトの中で、新しい取り組みがあるたびに一から作り直すのではなく、企業の垣根を越えて自由に使えるツールキットを作成することを目標として、コミュニティのメンバー多数に連絡をとりました。Netscape 4のサポート向けに構築されたツールキットには、非能率的な部分があまりにも多すぎたのがはっきりしていたので、初期のプロジェクト多数（netWindows、BurstLib、f(m)など）から最良のアイデアを取り出し、JavaScript利用時に楽ができるような新しいツールキットを作ることに決めたのです。自分たちがやっていることに価値があるとは思っていましたが、開発コミュニティへの影響やその広がり度合いについては見当もつきませんでした。
InfoQ: ツールキットのアーキテクチャについて概要を教えていただけますか。Dojoバージョン1.1.1(リンク)をダウンロードすると何が手に入るのでしょうか。
DojoはDojo Core、Dijit、DojoX、Dojo Utilitiesという4つの主要プロジェクトという構造になっています。標準のdojo.jsを入れるだけで、以下が可能になります。
- 非常に高速でサイズの小さい（gzip圧縮で26KB）コアには、XHRやイベント、DOM、クエリ、アニメーション、ネーム空間用のAPIや、その他頻繁に利用される便利な機能が満載です。
- 日付や色、戻るボタン/履歴、通貨などのオプションモジュール
Dojo 1.2では、ベースのビルドを6KBまで下げ、そこから構築できるようなオプションの機能を実際に提供しています。Dojoコアには、挙動システムや、一般的な正規表現、日付と通貨のAPIなど、オプションで入れられる追加コードも入っています。
Dijitは、ウィジェットのシステムであると同時に一般的なウィジェットのコレクションでもあり、つまり、デフォルトで使える優れたウィジェット一式と、独自のウィジェット一式を作成するための強力なシステムということになります。Dijitに入っているすべてのウィジェットは完全にアクセス可能、国際化可能であり、マークアップを介して目立たない方法でインスタンス生成することも、簡単なJavaScriptを介してインスタンス生成することもできます。Dijitには一般的なフォーム要素の更新や、カレンダー、エディタ、ツリー、スライダーなどが入っています。
DojoとDijitのすべてが本番環境に即応できると考えてよく、Dojo 2.0に向けてはAPI互換性の優先順位を高くして取り組む予定です。
DojoXはDojoの拡張という意味ですが、広く認知されていない機能や複雑な機能、まだ本番品質に達していない機能が入っています。たとえば、暗号化や追加のDojoデータストア、ベクトルグラフィックスをネイティブサポートするためのdojo.gfx、グラフ、オフライン、グリッドやその他のウィジェット、などなどです。DojoXの機能は1.xリリースに対しての下位互換性を保証していません。DojoXには有意義なコードベースが入っており、定期的に新しいものが追加され、つい最近ではXMPPクライアントやJSON-Schema、JSON-Referencing、安全なAjaxモジュールが追加されましたが、このすべてがDojo 1.2に同梱される予定で、現在のNightly Build版で利用可能になっています。
Dojo Utilitiesはその名のとおり、JavaScript開発者向けに数々の有用なユーティリティを提供するもので、以下が含まれます。
- JavaScriptファイルの結合、依存性の満足、HTMLとCSSファイルのマージのための非常に柔軟なビルドシステムで、Rhinoに少々手を加えたバージョンを基にしています。
- ShrinkSafeという圧縮ツールで、コメントや余分なホワイトスペースなどを取り除きます。これもRhinoを利用しています。
- DocToolは、ソースコードからAPIドキュメンテーションを生成するための高度先進システムで、複雑なミックスイン継承構造などの解決も可能です。
- DOH（Dojo Objective Harness）は、ブラウザとコマンドラインの両方で機能するユニットツールです。
Dojoは高度なモジュール方式で組織化されているので、必要とする機能だけを簡単に入手でき、そのためDojoでは、必要としない機能のためにシステム資源を浪費することはありません。
Dojoはオープンソースの財団でもあり、また、Cometd、DWR、Open Record、Psych Desktopといった他のプロジェクトの本部でもあります。
InfoQ: 今年のDojoには非常に勢いがあるように思われますが、特に今夏、O’Reilly(リンク)、Pragmatic Programmers(リンク)、Addison Wesley(リンク)から3冊の新刊が出版されたことを考えると、勢いは本物ですね。理由は何だとお考えですか。
まず、リリースしたバージョン1.0が安定していたので、書籍はあり得ると思っていましたし、Dojoについて著述することに興味を持ってくれる素晴らしい執筆者を探すこともできました。
機能面を考えると、優れた個々のコントリビューターの他にも、IBMやGoogle、Sun、Blue Coat Systems、Nexawebといった企業が、高速かつ強力、そして機能豊富なツールキットの作成に向けて、集中的にかなりの尽力をしてくれました。この質問に対する最良の答えは、一生懸命仕事をしてくれる素晴らしいコミュニティが私たちにはまさしくついていること、そして、Dojoを完全に書き直してさらに高速でリーンなツールキットに変身させようと数ヵ月を費やした2007年が明けて、これまでの努力が実を結び始めている、ということだと思います。
これはまた、私たちのコミュニティの育て方の所産でもあります。非常にオープンで透明性があり、有利なライセンシング（BSDあるいはAFL）を利用し、さらにCLAプロセスを使うことにより、ソースコードの利用について知的所有権の問題が絶対に起きないようにしています。プロジェクトのオープン度合いを表すDion Almaerの基準によると(リンク)、Dojoは100点満点です。
InfoQ: SitePenは数日前、Dojo開発者向けのAIRアプリケーションであるDojo Toolboxをリリースしました(リンク)。このツールボックスについて話していただけますか。
Adobeは、Open Web技術（HTML、JavaScript、CSS、Canvas、SVGなど）と同社所有のFlash/Flexスタックの両方をサポートするWebKitベースのプラットフォームをリリースするという興味深い行動に出ました。AIRにより開発者は、ローカルファイル・システムアクセスや、より優れたキャッシング、単一デプロイメント環境といったデスクトップアプリケーションの恩恵を享受できます。インストール可能なWebアプリケーションをWeb開発者が作成できる素晴らしい方法を、Adobeは完成させたのです。
AIRのリリースに先立ち、AIRに対するDojoのサポート改良に関して、まずAdobeからSitePenに話が持ち込まれ、その後、アプリケーション開発の共同スポンサーという提案を受けたのですが、それがDojo Toolboxという結果となったわけです。
Dojoには非常に大きなフィーチャセットがあるので、APIドキュメンテーションの印刷可能なPDFや簡単にビューできるストラクチャの作成は常に難題であり、そのため、18MBのDojoドキュメンテーションをオフラインで用意することに決めました。最適化したDojoビルドのバージョンを作成する簡単な方法を提供すれば便利になるとわかっていたのですが、AIRが素晴らしいソリューションとなったのです。このすべてをBSDライセンスで行いました。リリース後の数週間という短期間に、機能に関する素晴らしいリクエストを多数頂戴したので、アプリケーションの機能性を高める計画を立てています。私たちが作り上げたものは十分にモジュール化されているので、カスタマイズした独自のツールボックスビルドを作成したり、作成した独自のモジュールをツールボックスに提供してもらって、公式リリース入りする候補としたりすることができます。
InfoQ: Dojoのような純粋なJavaScriptライブラリのほかに、Javaの世界でWebアプリケーションを開発する人気が高い方法にGWTがあります。GWTはブラウザの様々な奇行のすべてを開発者にチェックさせないように努めるコードジェネレーターの役割を果たすため、GWTの機能の仕方は基本的に異なります。DojoとGWT、この2つの能力について、どうお考えですか。
開発者の好みや一番うまくいく組合せから選択する柔軟性を提供するというよりは、「YではなくXを選べ」という傾向が強すぎると思います。人々に選択を与えることが好きですし、実際、DojoをGWTにもたらすプロジェクトに現在取り組んでもらっています。.
Alex Russellが今年のGoogle I/Oイベントで行った講演のタイトルは「Can We Get There From Here」（ここからそこに到達できますか）でした。この講演のポイントの1つが、GWTはオープンであっても、GWTを使えば使うほど、分解が難しくなるということでした。複雑性の尺度で考えると、HTML/CSSが最も透過的であり、Dojoは、平易なHTMLやネーム空間などの機能がある単純なJavaScriptと比べて少し複雑になりますが、SilverlightやGWT、Flexとなると、ずっとデコンパイルが難しくなります。Dojoでは、コンパイルステップを完全にオプション化すると確定しました。GWTにはリロードボタンがありますが、それにはIDEの使用が必要です。GWTのコードオプティマイザはさらなるパフォーマンスブーストがもたらし、このパフォーマンスブーストをJS Linkerユーティリティで真似できればと思ってはいますが、ソースコードについてはJavaScript開発者がとても簡単に理解できるようなものに留めておこうと決定しました。
選択肢を試してみて、ビジネスにとって重要な要因を考慮に入れながら、最も生産的なものに決めるよう、みなさんに強くお勧めします。
InfoQ: 巷にはJavaScriptのフレームワークやツールキットがDojoの他にも数種類出ており、その成功度合いも、企業による採用度合いも様々です。Dojoが他と違うところはどこでしょうか。
Dojoの場合、IBMやSun、AOLのような企業や、その他SitePenの顧客を含めた多数の企業から、「今すぐ、この機能が必要」という広範にわたる実用的な改良要求を受けて、それに応えます。SitePenではオープンライセンスにしていますし、IP問題からアクセシビリティ、国際化のサポートにいたるまで、企業が重要視する詳細な点に配慮しているので、開発力の最適化を求めている企業にとって、SitePenは優れたオープンソースのソリューションになるのです。金融機関、軍部、政府を含め、多数の大規模組織がWeb開発モデルの至るところでDojoを使っています。こうした仕事の大半がAjaxの「暗黒物質」であり、ファイアウォールの裏側で使われています。
InfoQ: ECMAScriptの新版、バージョン4（別名JavaScript 2）に関与する組織(リンク)が今年、この言語の大要の改訂版(PDF)を発表しましたが、これが大いに物議を醸し、議論を呼んでいます。今回提案されたECMAScriptの変更(リンク) と、DojoのようなJavaScriptフレームワークに対する影響についてどう思われますか。
SitePenからはKris Zypが現在、ECMAScriptの作業グループに参加しています。私たちは実用主義者ですし、何事に関しても準備が整うまで待ってから手を出すので、これまでのところ、Dojo Toolkit自体への影響はほとんどありません。
私たちは一般に、良識をもって発言するように努めてきましたし、つまり駆け引きに偏ることなく、JavaScript開発者が言語から最も必要としていることに焦点を合わせてきました。この機能には意味がある、と確信している場合は後押ししますし、開発を困難にすると思われる変更には反対しています。
InfoQ: JavaScriptをふんだんに使用するWeb UIを作成する際、経験不足の開発者だと明確に理解できるとは限らない落とし穴がたくさんあります。有用性や検索エンジン、「戻るボタン」の動作、ブラウザパフォーマンスなどです。あなたからご覧になって、Dojo開発者が最も犯しやすいミスは何でしょうか。
単一のブラウザページや、ついでに言えば、あらゆるWebアプリケーションやソフトウェアアプリケーションでも、アクセス可能なシステムリソースには限りがあります。今おっしゃった問題の他にも、新米の開発者が陥り易いワナには自らの仕事の意味を理解していないことが挙げられ、たとえば、sub-secondのXHRで実装をポーリングしながら、1ページに動的グラフを100個実装するなどです。Dojo 1.0以上では「魔法」を減らすように努めたので、それぞれの機能には必ず犠牲がついて回ること、最速のツールキットは0KBであること、ほとんどの難しいことには手腕を問われるような決断とトレードオフが必要であることを、開発者がより理解できるようになっています。
開発者によく見られるミスにはこの他に、「ブラウザに矛盾はなく、合理的」と決めてかかることが挙げられます。「こうするにはこれが最良の方法」と長年唱えられてきた意見でも、間違っていて驚くことが頻繁にあります。Firebugのようなツールを使って単に「データを見る」だけでも、パフォーマンス障害が明らかになり、そのブラウザの真のパフォーマンス動作について、より理解できるようになるのです。
InfoQ: 複雑なJavaScriptフレームワークが構築されるということは、伝統的な「Webプラットフォーム」がすでにその潜在能力の限界に達してしまい(リンク)、もっと最新のもので置き換える段階にきている徴候であると言われています。これについてどうお考えですか。
過去4年間の発明の速度が速すぎて、ブラウザベンダーがより良いデプロイメント環境を構築する能力を大幅に上回ってしまっただけ、と考えています。ブラウザベンダーが非標準ベースのアプローチを試みると、酷評されることが多いのですが、これは不公平です。実験や新考案を行う余地がないなら、標準となり得るものなど何もないのですから。.
優れた開発エクスペリエンスの提供という点では、FlexとSilverlightはそれなりの仕事をしましたが、Open Webをまだ除外しないでください。現状を常に改善するための進化のアプローチは、実行可能な選択肢であると確信しています。たとえばWebKitはどうでしょう。ブラウザやAdobe AIRで使うアプリケーション、モバイル機器多数（もちろんiPhoneも含めて）、デスクトップやモバイル機器、任天堂Wii用Opera向けの優れた環境として成功を収めています。
JavaScriptツールキットは、Google Gearsなどに比べると、ブラウザベンダーよりも速くWebを更新するという点においては、良い仕事をしました。ブラウザベンダーは新しい特徴や機能を追加しますが、Dojoのようなツールキットはまずネイティブの実装を尊重してから、Web全体で改善の必要があるものを探すのです。
InfoQ: Flex(リンク)やOpenLaszlo(リンク)、Curl(リンク)のようなプラグインベースのRIAソリューションと比較して、純粋なJavaScriptフレームワークの能力をどのようにお考えですか。
かなりの能力があると思います。OpenLaszloはいろいろな意味で、FlashやOpen WebにデプロイできるGWTのようなコンパイラに、どちらかというと近いですね。面白いのは、私たちが別の方向を目指し始めたことです。ネイティブのベクトルグラフィックス向けにdojox.gfxはSVG、Canvas、VMLを一定期間サポートしてきました。最近、レンダラーとしてSilverlightのサポートを追加しましたが、その理由はIEのアルファビルドでVMLの損傷状態がひどいので、ベクトルグラフィックスとグラフのレンダリングでFlashとFlexの実験をしていたからです。ネイティブでローカルのストレージを持っていないブラウザでは、Flashのローカル・ストレージもサポートしています。.
再度申し上げますが、選択、そして実用主義を重んじるということです。
InfoQ: JavaScriptではある種のことができず、FlexもしくはFlaxhに頼る必要があると俗に言われています。その中には、たとえば図表化のように、非常に広く浸透している通説もあります。図表化やその他の分野に関する最近の取り組み(リンク)では、他の技術を使おうという動機がDojoによって抑制されているように思われます。JavaScriptライブラリの洗練度が増し、ブラウザによるサポートが向上すれば、プラグイン内からページコンポーネントを実装する必要性が最小限になると思われますか。
Dojoがあれば、ネイティブで不可能などんなことでさえも、その要求があればDojoを使って可能にできると私たちは確信しています。ベクトルグラフィックスと図表化に対する私たちのネイティブサポートは、非ネイティブのオプションと競合していますが、開発者が1つのソリューションしか使えないようにするよりも、どちらかといえばユーザに選択肢を与えています。未来の予測は困難ですが、プラグインの役割は一般に、ネイティブのオプションやJavaScriptを使って達成不可能なことを達成することです。最新の全ブラウザでベクトルグラフィックスをネイティブにサポートし、ブラウザ全域でdojox.gfxが実装の相違を隠しているので、この機能のためにプラグインを使う必要性は、不可欠というよりも、単なる選択となったのです。これもすべて、Open Webの自然的進化の一部なのです。
InfoQ: IE 7ではCSSのサポートが良かったので、デザイナーの仕事が楽になり、IE 8(リンク)ではJavaScript開発者の仕事が楽になると言われています。これまでの評判や詳細を考慮した上で、IEの次バージョンについてどうお考えですか。前進する大きなステップとなるのでしょうか。DojoのようなJavaScriptフレームワークに与える影響をどう思いますか。
時期尚早で何とも言えません。最初のリリースは2歩前進（2接続ではなく6接続、安全なクロスドメイン要求）、1歩後退（VMLにひどいバグ）のようなので、次のリリースには慎重ながらも楽観的です。
InfoQ: AJAXが広く知られるようになった2005年以降、一番最近の専門的流行語はCometです。用語法について議論している人たち(リンク)がまだいるので、Schiemannさん独自の定義を教えていただけないでしょうか。
Cometは、サーバーとクライアント間に低レイテンシのデータトランジットをもたらすための、テクニック、トランスポート、プロトコル、サーバー、クライアントの集合です。
XHRはCometの最小公分母であり、他のすべてはより高速かつリアルタイムのアプリケーションを提供できるように、XHRに改良を加える試みなのです。私の定義では、わざと避けている論点があります。その理由は、大部分の人にとってAjaxはブラウザ内の動的なものすべてを象徴するようになったけれども、私は包括的かつ広義に定義したいからです。
InfoQ: Bayeuxプロトコル(リンク)は、クライアントとサーバー間のJSON(リンク)符号化イベントのパブリッシュ・サブスクライブモデルでルーティングを促進しますが、BayeuxはCometアプリケーションを可能にする重要なコンポーネントのように見受けられます。この件について詳しく説明していただけますか。Bayeuxはその独自性により業界から事実上の支持を取り付けたようですが、たとえばW3C(リンク)を介してなど、正式の標準化に向かうと思われますか。
これまでのところ、Bayeuxの非公式的性質が大いに役立っていると思いますが、利益があるのであれば、標準化団体がやがては取り上げることになると確信しています。Bayeuxは、Cometdプロジェクトの一部をなすサーバーとクライアント向け標準プロトコルです。別のプロトコルのXMPPも、もちろん人気があります。HTML5の取り組みに対する最近のWebSocket追加の草案や、Orbitedプロジェクト内にすでに実装済みのWebSocketのAPI抽象化にも非常に興味があります。
InfoQ: Java領域では、Cometアプリケーションの開発方法(リンク)が今のところ数種類(リンク)存在します。Cometの標準的なやり方を定義するServletsバージョン3スペック（JSR 315）の出現(参考記事・英語)により、このジャンルのアプリケーションがどのように成長すると思いますか。
Javaスペースでは、LightstreamerやCaplin Liberatorといった無料バージョンに加えて、Jetty、DWR、GlassFishなど、オープンソースの様々なCometサーバーオプションが利用可能になっていす。サーブレットの新仕様はすでにJettyとGlassFishで実験的にサポートされており、仕様が確定すれば、皆が利用することになると確信しています。
興味深いのは、JavaOneのJoe WalkerによってオンボードとオフボードのCometが区別されるようになったことです。あなたが選択するCometサーバーがどの言語で記述されているかは、あなたが選択した言語でクライアントに確実にアクセスできる（クライアントがWebベースであるか、WebサーバベースのクライアントがCometサーバーと通信できる）ことと比較すると、さほど重要ではありません。
InfoQ: Webアプリケーションは、JavaScriptを理解するクライアント（ブラウザ）をターゲットにするので、エンドツーエンドのJavaScriptソリューションがあれば道理にかなう(リンク)と言われています。これについてはどう思われますか。サーバーサイドのJavaScriptが主流になってきていると思われますか。
Jaxer（Aptana）やPersevere（SitePen）、AxiomStack（Axiom）、Phobos（Sun）などの出現は、サーバーサイドのJavaScriptが一般的になってきていることを物語っています。JavaScriptは現在、世界一ユビキタスなプログラミング言語で、まさにどこでも利用可能です。クライアントサイドで始めた人にとっては、PHPやPython、Java、あるいは他の言語の構文を習得せずに、サーバーサイドに手を伸ばせる優れた方法だと思います（しかし、Dojoユーザの大部分は、今のところ、より伝統的な経緯でDojoにたどり着いています）。
将来どうなるかはわかりませんが、同じJavaScriptのコードベースをあちこちで使う、とてもいい機会だと思います。.
InfoQ: 大きなJavaコードベースを扱う開発者を見かけることがたびたびありますが、JavaScriptと同じというわけにはいきません。その動的な性質と、Dojoのようなフレームワークが様々な組合せのクライアント（ブラウザ）をターゲットにするという事実を考えると、開発過程で特有の制限や難しさが課されるに違いありません。問題の追跡にTracを使う(リンク)他に、このような特定ジャンルのソフトウェアに特に効果的とお考えになるツールやプロシージャはどれでしょうか。
JavaScriptのコードベースでも、驚くほどのサイズのものがありますよ！SitePenでは最近、TracからRedmineに切り替えたのですが、その理由は、RedmineはTracの単純さを保ちながら、長い間あればいいのにと思っていた機能（依存性、予測、複数プロジェクト）がついているからです。Subversionは様々なツールにまたがって優れたサポートを提供するので、まだ使用しています。SitePenでは、出回っているほぼすべてのテキストエディタやIDEを使っていますが、尋ねる開発者によって変わります。
Dojo DocToolとDojoに入っているユーティリティを使っています。私たちが使用しているあまり一般的ではない開発ツールには、Windmill、Tito Web Studio、Charles、Versionsがあります。全体的な標準があるとか、Javaにあるような、大型コードベース向けの維持やリファクタリング用のベストの方法があるとかは申し上げられませんし、それほど高いニーズがあるかどうかも、定かではありません。.
InfoQ: Steve Yeggeが次に来る重要な言語が何であるかについて話をするとき(リンク)、（もしそんな言語があるなら(参考記事)）YeggeはJavaScriptのことを指しているのだろう、と皆が推測しています。YeggeがRailsフレームワークの重要部分をRubyからJavaScriptに移植した(リンク)という事実があるので、この推測には根拠があるようです。JavaScriptで仕事をしてきて、こうした種類の潜在性を感じますか。
もちろん感じますし、これはサーバー上のJavaScriptに関する先ほどの質問に結びつくと思います。この種のアプローチではPersevere(リンク)も例になります。Persevereを簡単に説明すると、HTTP REST、JSON-RPC、JSONQuery、HTTP Channelsといった直観的で標準ベースのJSONインタフェースを使った、持続性ならびに分散型コンピューティングのためのオープンソースのツールセットです。
InfoQ: Dojoの進化をどのようにお考えですか。次のステップは何で、今後数ヶ月間に何を期待できるのでしょうか。
短期的には、パフォーマンスの向上や、グリッド、図表化、ツリーとエディタなどのウィジェット、Dijitの全体的な外観と使い心地、フォームとデータのバリデーション、Cometクライアントの安定性、承認システム、等々の改善を続けます。また、おそらく2010年のリリースとなるDojo 2.0に目を向け始めています。つまるところ、印象的なWebアプリケーションのプログラミングや、そのアプリケーションのユーザに素晴らしいエクスペリエンスを提供することに関与する開発者のために、Dojoが引き続き役立ち、前途有望かつ効率的であり続けるように努めることにつきます。
InfoQ.comはRIA(参考記事)やJavaScript(参考記事)、Web 2.0(参考記事)に関する興味深い記事をもっと特集します！
原文はこちらです：http://www.infoq.com/news/2008/07/dylan_schiemann_qna