最近、WEBサービスのユーザーインターフェースでは、AjaxあるいはAjaxっぽいJavascriptが必須になってきています。つい最近まで、MVCフレームワーク （ Model-view-controller - Wikipedia ） によって、かなり整理が進んでいたWEBアプリケーションのアーキテクチャが、（いい意味で）かなり揺さぶられている雰囲気。
Javascriptで動的に変化するWEBページをつくろうとすると、XHTMLでValidなDom構造であることがすごく重要になります（document.getElementById()とか）。HTMLの構造化を進めていくと、必然的にデザインはCSSに集約されるようになるし、DomとCSSを操作するJavascriptに、コントロール機能が集中するようになる。
こうなってくると、ブラウザ側でも、MVCフレームワークのような概念が定着しつつあるのかな？と何となく思って、以下のような図にまとめてみました。
サーバーサイドで、MVCフレームワークが重要になった要因として、WEBアプリケーションの規模に応じて、とてつもなく画面遷移が多くなることがあげられます。画面遷移の制御をコントローラーに集約しないと、手のつけようがなくなってくる。
ただ、実際にWEBアプリケーションをつくって実感するのは、画面遷移の多くは「確認画面」「エラー画面」「設定画面」などの、ユーザーが主に使う画面以外が占めているという事実です。
Ruby on Railsなどの、高速開発を売りにするフレームワークが、Ajaxライブラリと近しい関係にあるのは、単にCoolな見え方を実現するだけでなくて、サーバーサイドの無駄な画面遷移を省略する意味もあるのかなと思います。
今までWEBサーバ上のControllerで行っていた処理の一部を、ブラウザ側のController（Javascript）に移譲する感じでしょうか。
MVCのModelでも、色々なWEBサービスAPIから取得したXMLデータを、JSONオブジェクトとしてブラウザ上に展開するなど、WEBサーバ側で持つ必要がないデータは、直接ブラウザに読み込んでしまう。
またViewでも、CSSでデザインすることを前提に、データ構造をシンプルな<ul>リストからなるDom構造で、自動的に生成するTemplate Engineとか。
なんだかこの半年ぐらいで、WEBプログラミングの環境が、かなり変わってきているような気もします。
ブックマーク & はてなスター
コメント
GreasemonkeyでもHTMLのドロドロにはよく悩まされます。「クライアント側で弄る人にも優しいWebページ」になってほしいものです。
Gecko ではある程度汚い HTML も DOM として扱えるような気もしますが。
そうなると HTML ページも M として扱えますね。
もはや V をサーバー側で生成する時代ではないですね。
# クラサバの復活っぽい気もしますけど
Strict な HTML が広まるよりもより汚い HTML を DOM として処理できる engine の登場の方が早い気もします。
そうですね。多分、実装方法は、色々なやりかたがあるのかもしれませんね。
あとは、自分が開発するときにやりやすいスタイルと、
それを汎用化したフレームワーク（Rails + prototype.jsみたいな）が、
どれぐらい一般的に使われるようになるかなのでしょうか。
（私はまだ勉強し始めたばかりですが）
良く勉強していますね！ 素晴らしい！
Web 2.0 から開発環境やら、利用環境、ビジネス環境が変わるような気がします。あなた方世代では今が一番面白い時期かも。大いに暴れて下さい。（良い意味でですよ。決して悪いほうには行かないで！）
Pure Javascript で MVCフレームワークみたいなの作りました。
雅 - Pure Javascript MVC Framework
http://bz2.jp/Miyabi/
全然更新してないですけどw