アルファギークに学ぶAjaxの本質(そしてビジネス上の価値)

by tanabe on June 13, 2005

奇しくも、同じ時期に同じテーマのエントリがあがっていた。

一つは、Adam Bosworth's Weblogの"Ajax reconsidered".

そしてもう一つは、Life is beautifulさんの「Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ

なんせ

実は、現在米国 Google で活躍している Adam Bosworth と Gary Burd と私は、マイクロソフトで Internet Explorer 4.0 を一緒に開発していた仲です。マイクロソフトが XML と DHTML の機能を初めて導入したブラウザーです。あの当時から、彼らとは「次世代ウェブ・アプリケーション」の話ばかりしていました。非同期通信の話とか、UIをブロックしないだとか、XML over HTTP の話はその時に始まった話です。ある意味で、Adam も私も、10年近く同じことを言い続けているわけですね。

なのだから、この偶然?だけでも歴史を感じてしまい楽しい。

 

まずは"Ajax reconsidered"の方を読んでみよう。

どんな話なのかは、del.icio.usのコメントできれいな紹介文があったので引用。

Adam Bosworth describes why Ajax is a succes now, as opposed to DHTML in the 90's, and what is required for it to become truly successful.

Adam Bosworthが、(90年代にDHTMLが成功できなかったのと対比して)どうしてAjaxが流行っているか?、そしてAjaxが本当に成功するためには何が必要となるのか、を解説しているわけです。

まずは1997年にDHTMLやXML over HTTP control 受け入れられなかった背景を解説。

They saw the web as a two edged sword. One the one hand it offered instant and universal access to all their customers which was an opportunity they couldn't afford to resist. On the other hand, they were terrified by the support costs of having millions or tens of millions of customers using their software. Accordingly, they wanted applications (aka web sites) that were as simple to figure out how to use as possible.

Webには二つの面があり、とても便利で強力なネットワークを持っている反面、利用者の数が膨大でサポートのコストがとんでもないことになるという難点もある。だから、webへ求められるのはとにかく使い方が分かりやすいアプリケーションなのだ。(”だった”)という指摘。

Webは顧客へアクセスするための一手段でしかなく、たまにしか使われないwebアプリを機能豊富なインターフェースで組み立てて、無駄にサポートコストをかけるのは避けたいというのが97年当時の企業の考えだったようだ。

そして現在、Ajaxは大きな注目を集めている。さて、なぜだろう?というのがここからの話。

Adamは三つの理由があると言っている。

First, the applications that are taking off today in Ajax aren't customer support applications per se. They are more personal applications like mail or maps or schedules which often are used daily. Also people are a lot more familiar with the web and so slowly extending the idiom for things like expand/collapse is a lot less threatening than it was then. Google Maps for example uses panning to move around the map and people seem to love it.

一つ目の理由は、そもそも顧客サポートが必要とならないような日常的で一般的なアプリケーションでAjaxが使われているということ。メールや地図、スケジュールといった普段から馴染んでいるソフトとして提供されているため、直感的に使い方が分かり、前述のサポートコストが云々という話にはなり難いという指摘。また、ユーザー自身がコンピュータのUIに慣れてきており問題となりにくいというのも理由だろうと述べている。

Secondly, the physics didn't work in 1997. A lot of Ajax applications have a lot of script (often 10 or 20,000 lines) and without broadband, the download of this can be extremely painful. With broadband and standard tricks for compressing the script, it is a breeze. Even if you could download this much script in 1997, it ran too slowly. Javascript wasn't fast enough to respond in real time to user actions let alone to fetch some related data over HTTP. But Moore's law has come to its rescue and what was sluggish in 1997 is often lightning quick today.

二つ目の理由として、1997年にはネットワークやクライアントのインフラが力不足だったのが、近年克服されているということ。動的に呼び出されるコードを含んだページを読み込んでもダウンロードが遅すぎたりもせず、動的に一部のコンテンツを呼び出してもそれがストレスとなることはなくなった。これがあって、初めてAjaxが本来の快適なUIの実現に貢献できるようになったわけだ。

Finally, in 1997 or even in 1999 there wasn't a practical way to write these applications to run on all browsers. Today, with work, this is doable. It would be nice if the same code ran identically on Firefox, IE, Opera, and Safari, and in fact, even when it does, it doesn't run optimally on all of them requiring some custom coding for each one. This isn't ideal, but it is manageable.

最後の理由として、ブラウザ間の互換性を保ったままwebアプリケーションを書くことができるようになった点が挙げられている。同じコードで動けばそれで良し、もし動かなかった場合でもそれぞれにカスタムコードを書くとかで問題を回避することはできるようになった。つまり、ブラウザによらず、とりあえずは役立つ物になるわけだ。(ブラウザ個別にコードを書くのは美しい解決策ではないかもしれないけど、ユーザーへ問題が表面化することにはならない)

以降は、Adamの息子、Alex BosworthのAjaxへのダメ出しエントリから漏れていたAjaxの弱点についての考察が述べられている。

ここは一つだけ、引用しておく。

Third, if you want the application to run offline, you are essentially out of luck. I've written about this at length before in this blog and don't need to repeat what is required in detail. To summarize what I said earlier, a local cache, a smart template model, and a synchronization protocol are required to build applications that run equally well connected and disconnected and the way that the Blackberry works is a role model for all of us here.

Webアプリケーションが良いって言うのはわかったけど、オフラインだったらどうすんの?って話である。誰でも気付ける問題だけど、誰でも気付けてしまうがゆえに根強い課題だ。Web側で情報をドライブしようとしたときに最後までしぶとく残る問題のような気がする。(切り替えられない人は置き去りにするっていう手もあるけど)

 

そして、ここでもう一つLife is beautifulさんの「Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ」の方を読んでみよう。これ、最近で一番感動したエントリです。明快でスマート。

Googleなどが進めている第二世代のウェブ・アプリケーションのアーキテクチャーの本質は、XHTMLやXMLやJavascriptにあるのではない。その本質は、

(1)アプリケーションの明示的なインストールが必要ない。
(2)サーバーとの通信を非同期に実行することにより、通信遅延によりUIをブロックしない。
(3)サーバーとのやり取りは、RPCではなく、メッセージで行う。
(4)データ・バインディングはサーバー側ではなく、クライアント側で行う。
(5)UIにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。

の5点にある。

日本語なので、読んだまま、です。各項目の補足説明も引用元にあるので未読の方はぜひご一読を。私のこんなエントリよりもはるかに価値のある濃い文章です。

 

この両エントリを読んで頭の中がすっきりと整理された。そして、Ajaxはやっぱり末端技術なんだよなぁと思う。技術的には面白いのだけど、それ自体が力を持つようなもの(例えばOpen Source Paradigm Shiftで指摘されるような内容)ではないということ。なんせ出自が現在のWebアプリケーションの弱点となる部分を打破するための”やり方”でしかないわけだ。”やり方”が思いつかれたことは偉大だし、それが実現できるようになったことも非常に重要なことであるけれど、一度思いつかれ、実現方法が周知されたらそれはもう競争力にはなり得ない。

つまり、面白いけど本質的に競争優位性を保つような強力なものではないよってことだろう。大雑把な言い方をしてしまうと、ビジネス上は「UIは大事だよね。より良いものを提供しよう」という方向性さえ合わせておけばいい。適切な時にはAjaxという”良いツール”を使うこともできる。ちょっとした外部要因でAjaxはまったく必要なくなるかもしれないしね。くらいの認識でいいのかもしれない。(とはいえ、現在の環境下ではUIを良くする強力な手段であることには何の異議もない。はてなRSSの「もっと読む」なんか、動きだけで気持ちいいと思うし。)