6/08/2005

Ajaxの「本質」?

Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ

全体的にDisagreed.
>> 最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。
え。聞かないよそんな声。そんなこといってるのは四文字熟語大好きマーケッターと、コラムの締め切りに追われてネタがない記者だけでしょ?ってまあそれはいいとして、これって、こないだのAdam Bosworthの話(を受けて、だよね?全然出展が書いてないけど)を取り違えてると思う。確かこの5点に関するスライドをAdamが示して説明していたような。<誰かConfirm please。

まず第一に、これら5点は自明でもなんでもない。自明ってのは証明する必要がないってことでしょ?証明されてないと思うけどな。
(1)アプリケーションの明示的なインストールが必要ない。
それはそうだけど、それはWebアプリケーションの「本質」ではないでしょ。だってインストール・レスなこと自体はaccidentalじゃないか。たまたまいまどきのPCにプレ・インストールされてるだけ。Firefoxは明示的なインストールが必要でしょ。Greasemonkeyもそう。本質は、Web上にあるデータにはどこからでもアクセスできるってことの方で、アプリをインストールしないこと自体が本質なわけじゃない。
(2)サーバーとの通信を非同期に実行することにより、通信遅延によるUIのブロッキングを避ける。
これはAgreed。ただし、今Ajaxだ!といわれているサイトのほとんどはこれをあまり重視していない。いくらAにしたところで、返ってくるデータを待たないと次の処理に進めないようでは、Aの意味が全然ない。Ajaxを自慢するアプリやライブラリでAの部分を実装するものはまれ。
(3)サーバーとのやり取りは、RPCではなく、メッセージで行う。
Disagreed。まず、ネットワーク遅延云々という話は要するに送受信するデータ(ひいてはエンドポイントが持つ公開機能)の粒度のことを言ってるようにしか読めないが、粒度とRPCやMessagingといった作法とは直接関係ない。RPC(あるいはシームレスプログラミング)という言葉が代表するのは、実行環境ロックインのこと。RPCのシステムは、実行環境がクライアントとサーバーで共通であることを暗黙の前提とする。DCOM然り、CORBA然り、RMI然り。Bosworthが言っているMessagingとは、単にメソッド呼び出しの粒度を大きくしましょうなんて話ではない。RPCヘッダーの内容を読み取れないシステムでは、データが役に立たないような実行環境の固定化を象徴する言葉がRPCで、そうではない、ヘッダーはトランスポートのためのデータ、ボディは最終受信者のためのデータという具合に処理できるかどうか、それがメッセージングという言葉の意味だ。粒度が粗いとかいう話は、この前提から来る副産物に過ぎない。
そして、RPC vs MessagingなどAjaxの本質でもなんでもない。GmailやGoogle MapsがもしAjaxなんだとしたら、これらのアプリがやり取りするデータは高度に最適化され、完全にこれらのアプリに閉じている。ヘッダーとは無関係にボディを読めるようにするという話と、これらのアプリの作りは全然マッチしていない。また、仮にこれがタイトルをミスっただけで実は粒度の話なんだとしても、これらのアプリは実はフロントとバックとの間でやり取りされるデータサイズを小さくする(=粒度が細かくなる)ことで最適化しているように見える。
(4)データ・バインディングはサーバー側ではなく、クライアント側で行う。
これはAgreedなんだけど、以下で述べるようにこの筆者の論旨とかみ合ってないと思う。
(5)UIにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。
「インテリジェンス」「ある程度」...これが自明だなんて。それにやっぱり筆者の論旨とこのポイントはかみ合ってない。

とまあ細かいツッコミはあるが、筆者の論旨にもっとも共感できない点は、まずAjaxを「非同期メッセージ型ウェブ・アプリケーション」とイコールであると理由もなく決め付け、そして、「非同期メッセージ型ウェブ・アプリケーション」のプログラミングには必ずしもHTML、Javascriopt、XMLは必要ない」とする点にある。そもそもこのブログ記事の欺瞞は、最初の決め付けにある。Ajaxは、「非同期メッセージ型ウェブ・アプリケーション」なんかではない。

Aが非同期であることには異論はない。だから上の2点目にも異論はない。だがjaの部分は無視してはいけないのだ。なぜ、jaなのか。それは、たまたまプレ・インストールされているWebブラウザが大同小異で解釈できる唯一の実行環境だからだ。上の4と5(実は同じことをいっている気がするが)が本質であるのだとしたら、それは「今まではそうではなかったのにAjaxがそれを可能にしたから」であるはずだ。事実、今までは不可能だったように思えたIEとIE以外の両方で動く「Aja」なWebアプリケーション、上の(1)、(2)、(4)、(5)を満たすアプリケーションをjavascriptで書けることを、図らずもGoogleが世界に思い起こさせたからこそ、今のAjaxブームがあるのだ。「ja」があってこそのAjaxであって、jaを無視する議論はAjaxの説明になりえない。Ajaxは「非同期メッセージ型ウェブ・アプリケーション」などというチンケで「made up from the air」なマーケティング用語ではない。今そこにあるプラクティスを他人に説明するために便利なように後付けされた名前なんである。プラクティスが先。

メッセージングの部分に触れていないが、メッセージングなんてのは、AjaのAを実現するために利用できる唯一のプロトコルであるHTTPがメッセージングのためのプロトコルだったから、なんとなくそうであるように見えるだけ。JSONでやり取りされるデータが(まあJSONライブラリはいろいろあるにせよ)XMLで構成されるドキュメントと同じように「メッセージングっぽい」とは、僕には思えない。RPCでやり取りされる、暗号めいた、「わかるやつにしかわからない」データと変わらないでしょ。

XMLがAjaxの本質でないという点にはAgreed。でもそんなのみんな知っててあえてAjaxっていってるんでしょ?JSONとか使われてるじゃない。xを否定することがAjaxの本性を暴くことにはつながらないな。

そういうわけで、あのブログエントリで説明されているのはAjaxの本質でもなんでもない。また、非同期メッセージ型・Webアプリケーションの説明として正しいとも思えない。逆に筆者のほうが、Ajaxというプラクティスと非同期メッセージ型・Webアプリケーションというコンセプトを混同していて、Ajaxというプラクティスを前提にした議論を、非同期メッセージ型・Webアプリケーションというコンセプトの説明に持ってきているように読める。さらに、非同期メッセージ型・Webアプリケーションが「第二世代のウェブ・アプリケーションのアーキテクチャーの本質」だともいっているように読めるが、「第二世代のウェブ・アプリケーションのアーキテクチャ」とはそもそも何のことを言っているのかよくわからない。

そういうわけで、I disagree on the article. 「Ajaxの提唱者たちは、『HTML+Jascript+XMLを使ってウェブ・アプリケーションを作ろう』」と最初から主張している。「『非同期メッセージ型ウェブ・アプリケーションを作ろう』という主張と」「一緒くたにして発信し」ているのはこの記事の筆者であってAjaxの提唱者たちではない。

それからこれは自分への戒めでもあるのだが、「本質」という言葉を使う人が物事の本質を語った事例は多くない。

0 件のコメント: