リッチUIへの渇望
このような「もったいない」状況に対して、考え直す動きも始まっています。それは、「リッチクライアント」や「デスクトップ・アプリケーション」などの見直しの動きです。1990年代後半から、Webブラウザーも単なる端末装置ではなくプログラム実行が可能となりました。それがJavaScriptを中心としたDynamicHTMLです。DynamicHTMLを使うと、Webブラウザー上でプログラムを実行することができるため、操作そのものを処理するプログラムをパソコン上で実行できます。プログラムはHTMLドキュメントに埋め込んで配信するため、個別にパソコンにインストールする必要はありません。欠点は、JavaScriptで取り扱えるデータは、埋め込んだ定数などだけである、という点でした。
JavaScriptにサーバーと通信する機能（XmlHttpRequest：XHRや、JavaScript Object Notation：JSONなど）を追加し、クライアントサーバー型で動作させられるようにしたモデルが「Ajax（Asynchronous JavaScript and XML）」で、Web 2.0の中心となる技術です。 CSSの進化やDOM-APIの採用などで、JavaScriptで表現できるUIの技術も向上したことから、Webアプリケーションの守備範囲を大きく発展させました。
別の流れとしてリッチクライアントの流行も挙げられます。これは、W3Cが規定するHTMLやCSS、ECMAが規定するJavaScriptといった枠にとらわれず、独自の考え方、独自のアーキテクチャーにより「よりリッチな端末ソフトウェア」を提供しよう、という流派と考えるといいでしょう。単独で動作するクライアント・ソフトウェアや、ブラウザーにプラグインするソフトウェアを使って、簡単なプログラミングでリッチなUIを実現できるようにしよう、というコンセプトです。
しかしながら、当然のことながら「もっとリッチな」ものを必要とする場面がなくなったわけではありません。とくに、図形の回転や画像変換などを伴うような複雑な処理や、3D表示を行うための特種なAPIやハードウェアのアクセスなどを実施しようとすると、ネイティブ環境に近いプログラミング言語が必要とされます。Java、C#、C言語などによるソフトウェア開発は、今でも必要とされているわけです。
DynamicHTML、Ajax、リッチクライアント、ネイティブ・ソフトウェアなどは、すべてクライアント（パソコン）側でアプリケーションの一部を動作させよう、という考え方に基づくものです。この記事では「デスクトップ・アプリケーション」と呼ぶことにします。
これらリッチUIの再検討はクライアントサーバーの再来と言えなくもありません。市場は集中と分散を揺れているのです。しかし、過去の失敗をふまえ、アプリケーション・モジュールの配布基盤、認証やサンドボックスなどの技術の進化、データの安全な分散方法とレプリケーション技術などを搭載したソリューションの登場が、今日のやりかたと言えるでしょう。
