Not too fat, not too thin: the rich client

The only way to eliminate, or at least minimize, the disruption in workflow caused by server lag is to download data and functionality directly to the user's computer. Only then can the user manipulate the data with the near instantaneous response of a true local application. But how much should you download to the user's local machine?

With a client-server application, you have a wide spectrum of implementations, from fat client to thin client. An extreme fat client downloads the entire application and only calls the server when data needs to be exchanged. The application's entire UI, along with all application logic, resides on the user's machine. At the other extreme, a thin client downloads only a small parcel of data with a minimal set of UI.

A fat client application's enhanced performance comes at the expense of a significant initial download and installation. As such, any changes to the application require a laborious upgrade across the entire user base. In addition, fat clients are not built on frameworks as open as traditional Web applications. Thin client applications allow ease of development, deployment, and upgrading; however, the user usually suffers from the delayed ping-pong of client-server communications. The best solution today lies in the middle of these two extremes: the rich application.

Defining the spectrum of client-server architectures

So what exactly is a rich application? No binary answer distinctly defines it. Even within the niche of rich applications, a wide spectrum of rich client functionality exists. Applications developed using Macromedia's Flash are often referred to as rich applications. But such applications require a browser plug-in along with the specific application download. Depending on how you utilize Flash, the application can fall in the rich client category or in the realm of fat applications.

The same holds true at the opposite end, where HTML Web applications using basic CSS and JavaScript provide enhanced client-side interactions and data manipulability. Such applications teeter between thin client and rich client. While the rich client lies between the thin client and the fat client, it comes in many gradations. Essentially, a rich client offers nearly the same deployment ease as a thin application with nearly the same enhanced interactivity and usability of a fat application, along with improved server resourcing.

Strike it rich

Rich clients certainly sound like the optimal method, so why haven't they been widely used? Until recently, the browser market has been plagued with high fragmentation and immature functionality. With the browser serving as the primary platform for most Web applications, the task of developing advanced client-side functionality has been extremely difficult.

Two major events transformed the landscape. First, by exposing the DOM, the W3C has developed and stabilized universal standards for defining advanced client-side functionality. Second, while Microsoft's Internet Explorer clearly dominates the browser market, it generally supports those standards. This means UI designers and developers now have a fixed, robust platform and can feasibly create rich client applications that leverage advanced, instantaneous, client-side interactions.