Skip to main content

I like thin clients because of their simplified programming model

Posted by satyak on November 15, 2003 at 7:51 AM PST

I like thin clients because of their simplified programming model

Thin clients may not be as programmatically rich (they can certainly compete with visual richness) as thick clients. But the bargain is that their (thin) programming model is simpler and consistent. It is a completely different matter that some tool sets try to infuse sophistication into the thin client model with out giving much thought if the solution is sacrificing the simpler programming model.

What is this simpler programming model that I am talking about?

To start with thin clients by default enforce three tier architecture with out making the middle tier an extra burden. The semantic of this tier is nicely encapsulated by web servers and web plugins such as tomcat. Tomcat will deal with threads and possibly transactions, and other container semantics. The programmer is relegated to write only the business logic.

The communication between the presentation and the middle tier is largely expected to be a request/response architecture. You ask the middle tier for a chunk of data and you render that chunk. HTML gives you a limited set of controls and tools to manage the presentation space. So there is a clear separation of views and data. Unlike the thick clients the focus in a thin client is the page as opposed to sections of the page. It is possible as in asp.net and JSF to take a view that is based on user controls. Although this view is applicable where the sophistication is needed the approach is more than warranted for simpler to medium sized applications. The argument is that when you sacrifice simplicity of a thin client you may be better of using java webstart and applets. I am sure there is a good middle ground where JSF makes perfect sense.

Because of the insistence of thin clients on request/response models, it is easier to provide value added services to your distributed application. Security, monitoring, clustering, usage stats etc.

Because the architecture of thin clients is chosen by standards, programmers have smaller role to impact the scalability of the solution.

Think client applications should be much faster to develop

Because the programming model is simpler, thin clients must be much faster to develop. When this is not the case, the main culprit is that you are using a complex architecture to solve the problem at hand. The development cycles should go from 6 months to a year to 3 months to 6 months. You should also get benefits from the kind of skill sets you need to develop.

You might argue that thick clients are faster to develop. But I ask, if this is true, it should have been true a couple of years ago when there were no thin clients around. The average project cycles in those days used to be about a year for a small to medium sized client server app.

Doesn't mean you can't make thin clients overly complex

Imagine a thin client application that uses the full blown J2EE. For example use JSF for the client, Use session bean facades, and use entity beans container manager persistence. Although I haven't done this, my suspicion is that it will take a while to get your system out. These solutions are remarkable in their own right but will add complexity to your thin client platform. If the thin client platform is complex enough to warrant the big guns, sure thing use it.

Related Topics >>