« Ajax は難しい? AHAH ならどうだ | メイン | 37 Signals のビジネスモデルはあくまで Web デザインコンサルティングなのだろうか »

2005年11月28日

AHAH (アハー)補足

昨日のエントリ Ajax は難しい? AHAH ならどうだ で紹介した AHAH だが、別に「AHAH が AJax を置き換える」とか「これからは AHAH だ」とか言いたいわけではないよ。

Web クライアント-サーバ間(の lazy な、とか、部分的な)データ伝達を考えたときに、Ajax というのは「XML であること」をけっこう重視して宣言された。

XML でデータを流通させるのにはやはり意味があって、同一のデータを基にクライアント側で表現方法を複数切り替えるとか、描画にクライアント側のマシンパワーを積極的に使いたいとか、であれば XML ぜんぜんオッケー。また、サーバ側から提供される XML データを、広く公開して他のクライアント(や他のサーバ)でも使ってもらおう、というときも、標準である XML を使うことの意義は大きい。AHAH でそんなもの提供したら、読む側は独自 HTML を読むための HTML パーザを使わなきゃならなくなる。

データも公開するけど、関係するデータ利用者のほとんどが Javascript だった場合、JSON みたいな話が出てきて、クライアントがそのまま使える形にすることでクライアント側の手間を省くのに成功している。なんでも XML は止めて、実用的に考えようよ、というのが JSON だったと思う。

AHAH もそれと同じことで、XML であることや JSON であることに意味が無いようなデータに、無理矢理複雑なデータ構造を使うのは止めたほうがいいんじゃない、というだけのことでしかない。誰も途中でそのデータを横取りせず、送られたものは結局表示するだけ、だとしたら、サーバ側で整形したものをそのまま返したほうが楽じゃん、という。ようは適材適所、ということだ。

「Ajax といいつつ、部分ページを送ってるだけなんだよなあ」というようなことに後ろめたさをこれまで持ってた人たちがいたとしたら、AHAH という定義やその理論的な補強をするページが存在することは、いいことなんじゃないかな。

投稿者 秋元 : 2005年11月28日 17:48

トラックバック

このエントリーのトラックバックURL:
http://labs.cybozu.co.jp/cgi-bin/mt-admin/mt-tbp.cgi/254

コメント

内容的にはほぼ同意ですが、
>AHAH でそんなもの提供したら、読む側は独自 HTML を読むための HTML パーザを使わなきゃならなくなる。
そこで、AHAHを提唱してるのがmicroformatsな人たちなのがポイントかなと思ってます。たとえばtag cloudを AHAH で読み込むなら、rel-tag 使えばいいと。
http://microformats.org/wiki/rel-tag

投稿者 miyagawa : 2005年11月29日 01:18

なるほどー。rel-tag などの microformats なら、そのまま表示もできるし、機械的な処理もできますね。

AHAH のデータモデルには microformats を、というセットの提案であるということですか。勉強になります。

投稿者 秋元 : 2005年11月29日 10:32