シンとリッチは喧嘩しない？

Curlをはじめとする「リッチクライアント」に対して引き合いに出されるキーワードの1つに
「シンクライアント」というものがありますが、
「リッチクライアント」と「シンクライアント」は本来、対極となるものではありません。

「リッチ」というのはアプリケーションの操作性に主眼が置かれた言葉で、
一方の「シン」はクライアントマシンにアプリケーションを保存するかどうかを表しているわけですから、
そもそも機軸が違うのです。

「シン」の対義語はいうまでもなく「ファット」、つまり、クライアントマシンにアプリケーションを
保存する仕組みです。
アプリケーションの更新のたびにフロッピーやＣＤなどで配布をしなければならない環境においては、
この「ファット」という仕組みはメンテナンスコストのかかるものでしたが、
もちろん、「ファット」自体が悪いというわけではありません。

「リッチ」の対義語は「シン」ではなくやはり「プア」と定義すべきでしょう。
主に、何か操作をするたびに通信を待つことだと考えればよいと思います。
「シン」に対応する「ファット」とは異なり、
この「プア」な仕組みによる操作性の悪さは生産性の低下に直結し、
それ自体あまりよいものではありません。

時折「リッチvsシン」という対立構造を思い浮かべられる方がおられるのは
これまでの「シン」なアプリケーションの多くが「プア」であったためでしょうが、
「シン」であるWEBブラウザの上で「リッチ」なAjaxが動いていることを考えれば、
その意味でGoogle Tools等は「シン」でもあり「リッチ」であるといえるでしょう。
一方、Windowsオフィスのエクセルは「ファット」ではありますが、非常に「リッチ」なものです。

Curlの場合、アプリケーションをキャッシュとしてクライアントに残すことも出来ますし、
まったく残さないようにすることも可能です。
また、レプリケーションとしてクライアントに保存し、
通信が出来ない環境でも動かすような仕組みもとることが可能です。
そういう意味でCurlは「シンでもありファットでもあるリッチ」なアプリケーションが構築できるわけです。

「金持ち（リッチ）喧嘩せず」といいますが、
「シン」や「ファット」といった環境に左右されずに操作性の高い「富（リッチ）を生む」アプリケーションを
構築されたいと考えておられる方は、
一度、Curlをはじめとするリッチクライアントを検討されてはいかがでしょうか。