« NetBeans Feels the Refactoring Heat | Main | Thick and Rich Like Snickers Cake »

Thick Client : Thin Client :: Red Pill : Blue Pill ?

Now that the Web has finally invaded just about every corner of life and the magic of "thin client" has been applied to every conceivable application we can finally as ourselves the question "is this the right thing to do" rather than "can we" or "how do we." the answer to the second is "yes" and with some Googling the answer to the third is within easy grasp. But these two beg the first question, of "should we." At my company we started out our first pass on the GUI as a pure think client DHTML nirvana. At the time the think client kool-aid was quite strong and everybody bought into the vision of it. We didn't have any real serious discussions on any non-html solutions. We have since started going down the swing path for various reasons. It wasn't a bad thing we started out thin, because if we started out thick we would have certainly have been asked the question about why we don't just do it in HTML. Now people can see the difference and for waht is wanted it is a real value.

But thick isn't always the answer. Sometimes thin is the way it should be done. But when and which? Here is a bullet list based on some of my experiences, dating all the way back to when NetDynamics was sold by a company called Spider Technologies.

  • Scale - This is actually two questions, with different answers for each extreme based on the way you ask it.
    • Number of Users - How many users are going to be using this application? If it is large (hundreds to thousands per instillation) then a thin client avoids messy install issues. If it is small then either way.
    • Amount of Data - How much data is the user expected to handle. It's not about how much water is coming through the hose but how big the nozzle is. To much data coming through a thin client is like a fire hose. But on a thick client it can look like a meandering river. Lots of data at once means go thick
  • Interactivity - Is the interface meant to be highly interactive? We're not talking just mouse overs and hovers. Resizable and removable column headers have a hight cost associated with then in a thin client. Similarly a frequent need to update data on the server can place a heavy load on the server application if done poorly, even if done smartly. A thick client can more easily update a small piece of data without dragging back across the wire a large amount of strictly visual effects, such as adding a new node to your typical tree control.
  • Rich UI Controls - How much control do you need over the UI controls? Editable ComboBoxes/SelectBoxes are one example that are all but impossible to do well in HTML. A rich table control with sortable columns that can be dynamically resized and have columns removed showing thousands to possibly millions of rows can be done with HTML through various HTML and serving tricks, but the tend to work better when thick. Some controls can be emulated "good enough" in HTML with scripting, such as calendar selects and formatted fields, so that may work for thin. But plain old goofy controls will requires some meat on them bones.
  • Frequency of User Use - How often is the typical user going to use it? If it's once a month they won't endure a 10 minute install, like your typical online banking app. But if it is continually used they may want a client image, like an Instant Messenger client. Some frequently used apps can be done well with a thin client, but that's because the UI is simple

Thin clients are good, but I think they are being over-done. When I hear of people writing a UI that 10 people at each large client will be using all day with rich table controls and massive amounts of data pushed through it being written as a DHTML web app it makes me want to take the blinders off and introduce them to old friends like Applets and new friends like WebStart. After all, thick is the big trend.

Comments (3)

YourThick:


Are you implying the Swing == thick ?????

This is completely false.A Swing client could be thick or thin. Go back to school.

In that you need to download a 10MB plug-in to get the 1.4 version it is thick. And you need admin priviliges to install (which most non-software development enterprises dont give out). And in all of my professional experience and research I've never seen java considered a thin client beside DHTML.

Besides, why should I take shots from a coward who won't even leave his real contact information?

Neil Weber:

I think the "thick" and "thin" terms are too misunderstood. They were originally used when people were putting all of their business logic and database queries into the client. Now that many people are doing multi-tier and *not* putting database code into their client "thick" doesn't really apply. Sun has been using "rich" for this type of client.

In any case, substituting "thick" with "rich" in your blog entry, I agree with what you have written. Except that in an IT environment, it isn't painful to install the client software on desktops. We use MDE (managed desktop environment?) to push the client software.

BTW, it isn't necessary to be admin to install the JRE. I install the JRE into a subdirectory of my client app and it works fine. The JRE is not registered in the registry so I don't have to worry about messing up any other Java app and I can upgrade the JRE at any time.

Post a comment


About

This page contains a single entry from the blog posted on November 21, 2003 10:16 AM.

The previous post in this blog was NetBeans Feels the Refactoring Heat.

The next post in this blog is Thick and Rich Like Snickers Cake.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33