予測できないITの行く先を、あちこち歩きながら考えてみます

2006年のAjaxはJavaScriptプログラミングが脇役になっていく

»

このところAjax系の話題が続いていてAjaxブログっぽくなっていますが、私がAjaxに注目している理由は、AjaxがWeb2.0の文脈で大事なテクノロジであると同時に、業務アプリケーションをWeb化するツール、言い換えるとリッチクライアントの技術としてもAjaxは大きな位置を占めそうだ、という2つの側面があるからなんですね。後者のほうが@ITぽいですけれど、それはさておき。

これまでのエントリに対してコメントやトラックバックをいただいてありがとうございます。どれも目を通しています。

さて、いただいたいくつかのコメントで「ベンダはバックエンド向けの製品へ投資をシフトさせているし、フロントエンド系はオープンソースで作れるようになってきているので、フロントエンド向けのツールでのメッセージが少ないのでは」というご意見をいただきました。私もそうだとは思うのですが、お金や手間を掛けないなりにも、Ajaxがからんだリリースを出すだけでもベンダにとっては話題になりやすいタイミングだと思うのです(私が見落としているだけ?)。

以前のエントリで「オラクルのJDeveloprがAjaxに対応する」と書いた点については、S/N Ratioの佐藤さんから、正確にはJDeveloperの「JSFコンポーネントOracle ADF FacesがAjax/リッチ・クライアント対応する」ということで、「直接『JDeveloperがAjaxに対応』というわけではないので…」とのご指摘をいただきました。ありがとうございました。JavaOneでデモを見たときに、すっかりそう思いこんでいました。

それから、「Ajaxの統合開発環境でもマイクロソフトが先行する予感」で紹介した、Apache Software Foundationに対してEclipse対応Ajax開発環境の開発提案が出された件は、続報をArclampの鈴木さんが「AJAX Toolkitの提案からIBMが抜ける」というエントリで書かれています。結局Eclipseの部分はごっそり抜けてしまうそうです。ちょっとがっかりです。となると、Ajaxの開発ツールの主役(もしくはデファクト)の座をめぐっては、もう少し紆余曲折がありそうです。

Ajax開発ツールの本命は?

Ajaxのアプリケーションの開発は、JavaScriptだけでなくCSSやXMLの知識も必要ですし、サーバ側のPHPやJavaのプログラミングやブラウザごとに異なる動作についても気をつける必要があるなど結構面倒です。

これまではこうした面倒をあえて引き受けた一部の優秀なプログラマが、手間暇かけてAjaxのアプリケーションを作ってきましたが、これからはこの面倒を省略するためのさまざまなライブラリ、エディタ、デバッガ、開発環境などが提供されるフェーズがやってきます。

そこで、どんなツールやライブラリが公開されているのか、分かる範囲でざっとリストアップしてみました。

・ASP.NET Atlas
http://www.microsoft.com/japan/msdn/asp.net/using/future/overview.aspx
・AJAX.net
http://ajax.schwarz-interactive.de/csharpsample/default.aspx
・AjaxBuilder
http://www.hows.ws/product/index.html
・Ajax Tag Library
http://struts.sourceforge.net/ajaxtags/
・AjaxFaces
http://www.ajaxfaces.com/
・prototype.js
http://prototype.conio.net/
・Dojo
http://www.dojotoolkit.org/
・DWR
http://getahead.ltd.uk/dwr/
・Rico
http://openrico.org/rico/home.page
・SAJAX
http://www.modernmethod.com/sajax/
・MochiKit
http://mochikit.com/index.html
・script.aculo.us
http://script.aculo.us/
・JackBe
http://www.jackbe.com/
・Backbase
http://www.backbase.com/
・ICEfeces
http://www.icesoft.com/products/icefaces.html
・ClearNova
http://www.clearnova.com/

たぶんこれでもまだフォローし切れていないツールが多くあると思います。それほどいまはAjaxの開発をサポートするソフトウェアがたくさん出ていますが、どれも基本的にはJavaScriptによるソフトウェア部品をあらかじめ用意しておいて、それを組み合わせたり呼び出したりすることで、簡単にAjaxアプリケーションができあがる、といったアプローチのものです(ライブラリもツールも一般的にそのような目的で使うので当たり前ではありますが...)。

JSFがコントロールの標準モデルとなるか

その中でも、Ajaxの部品をJavaServer Facesのコントロールとコンパチブルにしてある、というアプローチを見かけました。こうしておくことで、JSFに対応した既存のJavaの統合開発ツールから利用しやすくなる、というメリットは非常に大きいですね。

業務アプリケーションの開発に限って考えれば、バックエンドをJavaで書くことは非常に多いですから(@ITのリッチクライアント開発者へのアンケートでもJavaが一番でした)、JSFのコントロールがAjax化されるのは自然な流れのように思えます。

となれば、やはりAjaxアプリケーションの開発スタイルとして、
・Eclipse上でのようなビジュアル開発環境が用意されていて
・JSFのコントロールとコンパチブルなAjaxコントロールが多数用意されていて
・画面フォーム上にドラッグ&ドロップして属性を設定することで開発できる
というパターンが本命になると考えるのは自然なことでしょう。

もちろん、こうしたスタイルの開発ツールとしてすでにオラクルのJDeveloperもありますし、以前のエントリで書いたようにIBMもサンも用意しています(あるいは用意しつつあります)し、マイクロソフトのAtlasも同様のスタイル。ただ、(Atlasは.NET用ですから別ですが)これらはまだコントロールがツールの中で閉じていて、あるツールで用意されているコントロールをほかのツールで利用することはできません(よね?)。

そこで期待されるのは、やはりJavaでのAjaxコントロールの標準化。JSF1.2ではAjaxコントロールに対応する、という報道もあります。技術的に踏み込んだところは私は詳しくないのですが、これはJavaにおけるAjaxコントロールの標準化が実現間近(もしくはもう終わった)ということなのでしょうか。もしそうだとしたら、あとは開発ツールのほうでJSF1.2をサポートすれば、色んなところから標準対応Ajaxコントロールがどんどん出てくる、ということを期待していいんでしょうか?(詳しい方、ぜひ教えてください)

いずれにせよ、いまはAjaxというとJavaScriptを覚えて、DOMを覚えて...という感じですが、1年もしないうちに、JavaScriptプログラミングは必須ではなくなっていくように思います。大多数のアプリケーションプログラマは、“JavaScriptでできた部品を利用する”ことになっていくはずですし、よりよいアプリケーションを高い生産性を持って開発するためにもそうなってほしいと思っています。

Comment(3)

コメント

HN

Ajaxについていうと、なにかというと、HTTPリクスエストを送りたがるのが悪いWebインターフェース業務ソフトだとすれば、少しは、クライアントサイドに仕事をふってもいいのではないか、という、俯瞰してみればごく当たり前の反動としてでてきたのが、Ajaxなのだ。という見方をしています。

いい例が思いつかないですけど、例えば、ECサイトの、ショッピングカート機能において、どの商品をカートに入れたのかを、ウェブサーバにおけるセッションの仕組みを利用して保存するのか、それとも、どの商品をカートに入れたのかはクライアントサイドだけ、クッキーに保存するなどして、最後の商品注文処理だけ、ウェブサーバのプログラムへ送信する、のとどっちがいいかという話ですね。これは規模や商品内容といった、要するにサービスの性質による、という当たり前の結論になってしまうのですが、クライアントサイドだけで、シンプルに済ませられることがあれば、それを利用するのは当然です。

もし、さらに複雑なクライアントサイド機能が必要でしたら、そうなると、ウェブインターフェースではなく、ウィンドウベースのソフトウェアを作ることが有効なのだと、そういうことでしょう。そう考えると、Ajax に高度な開発環境が必要なのかという議論になると思います。今でも、Internet Explorer / Firefox / Opera / Safarii ブラウザ間のJavaScript の動作は、細かい違いがあるし、ウェブベースのソフトウェアということは、必然的に単純なプログラムになり、もし複雑なユーザインターフェースを提供するものが必要とされるのであれば、それはウィンドウベースのアプリケーション向きということでしょう。

となれば、JavaScript プログラミングに、ビジュアルな開発環境など、単純なプログラムでしか JavaScript を書くシーンはないのですから。

Java でAjaxというのは、つまり Java Applet の復権ってことでしょうかね。Java Appletのペースの上で、HTTPプロトコルでXMLデータを受け取て、そのデータを扱うJava Appletアプリケーションが、確かにそういう作り方が向いているケースもある場合もあると思います。ただ、いずれの選択肢も、これがオールマイティというわけではないことには自覚的であったほうがよいと思ってます。

再利用については、繰り返された議論ですよね。再利用する、とかってのは。過去のソフトウェア開発の議論でずーっと言われ続けたことです。

HN

(すいません、書き間違えが一部ありましたので、その部分だけ追記です。):

となれば、JavaScript プログラミングに、ビジュアルな開発環境など、不要。単純なプログラムでしか JavaScript を書くシーンはないのですから。

HNさん、コメントありがとうございます。ちょっと説明不足だったかもしれませんが、「JavaによるAjaxコントロールの標準化」は、JavaアプレットでAjaxを作るのではなく、HTMLを生成する部分のjavaプログラムであるJSFの中で、HTMLの一部としてJavaScriptも生成するための標準化、という意味で書きました。
JSFはJavaでプログラミングする際の標準技術として広く使われているので、それがAjaxにも対応したらAjaxプログラミングの敷居はぐっと低くなりそうだと期待しています。

コメントを投稿する