Is thin still in?

Nearly all Web sites and Web applications today are thin clients, with a data set and a minimal presentation layer downloaded to the user's PC, while the bulk of computational processing occurs at the server. The primary benefit of a thin client architecture model is deployment ease -- by changing the source in one location (the server), users are instantly upgraded when they return to the application. Compared to the behemoth task of manually upgrading a user base with a locally installed application, the effort required to upgrade users with a thin client application is minimal. The ability to easily deploy new application releases without requiring users to install additional software is very appealing.

With a thin client, you can maximize the one resource you have complete control over, the server, to do the brunt of the work and dish out a minimal set of data and presentation layer information.

Nothing but skin and bones

But how efficient is it to have a big powerful server crunch computations while countless client machines receive its information? Not very. In between the almighty server and submissive clients is a little problem called limited bandwidth and its resulting demon -- server lag. The user fills out an order form, submits it, and waits six seconds. A screen renders, showing errors in the form submission. The user attempts to correct the errors and resubmits. Twiddling thumbs, the user waits another six seconds. And on and on.

Even with the increasing availability of broadband, client-server delays (those greater than one tenth of a second) still pose usability problems. Users no longer feel like they're operating with the UI directly. At around 10 seconds, users lose their train of thought and you risk losing their attention. The server is powerful, but without a user accessing its data, it becomes ineffective.

Another crippling characteristic of thin clients is that nearly all user interaction is at the page level. Systems primarily respond to the user page by page rather than elementally at the HTML component level. Such macro-level system response is inefficient because many user interactions warrant an immediate response. The cumulative effect of executing smaller instantaneous interactions is often the most efficient way to accomplish a larger goal. Imagine if instead of keys for individual letters, a keyboard displayed keys for entire words. That would make things quite slow and awkward. And that's what best describes the interactions forced at higher aggregate levels. Such interactions are synonymous with thin client applications.