Thick or thin
But he stops too soon. While he mentions at the end that WebStart is a new friend, he didn't attach this to thoughts on the scale of deployment. A lot of people use thin clients to avoid sneakernet install issues for think clients, but in reality JavaWebStart is solving this problem now for think clients.
But one of the larger problems in my mind, that Danno didn't mention, is UIs for which the data presented is driven by events other than the user. Stock trading consoles that want to display dynamically updating quote information. Power grid managment wants to display real-time loading, current,voltage, frequency samples. Sure you can solve these problems with auto-refresh, but that has its own cost in extra reads (solving for accuracy) or out of date data (solving for bandwidth). Not to mention that the actual data that is updated is way way smaller than the whole page refresh. Again, bandwidth.
Another case was a web calendar I was looking at lately. Setting up a group for cross referencing calendars to find availability, required flipping through piles of screens to find a person's calendar, go to another to add it to the group, go to the search again to find the next person. Came to something like 4 screens per person added. Each with HTTP page loading times. Took forever. Totally crazy. Compare to some fat clients doing similar things in one dialog.
Some thick clients are a joy to use, while their thin counterparts make me want to use another product.
Fat vs Thin is certainly a valid argument to have, but I think that most
discussions rest of certain assumptions that dont have to hold true. The
biggest of these is the assumption that every user action in a thin client
requires a HTTP round-trip. Smart use of javascript and HTML makes it
relatively easy to avoid these things - the web calendar you mention is a
classic. The real argument there is, as Danno puts it, the amount of data
coming down the pipe. In my spare time atm I'm working on a training diary
aimed at rowers, available at http://training.coxless.com, which has a MS
Money style interface to viewing a diary, and works (I think) very
well.
Having said all that, there are plenty of times when a thick client works wonders - but the biggest argument from my point of view is the number of users. Having not too long ago finished a contract where a thick client was deployed to 60-70 users, and even at those numbers, deployment was an issue (mind you they refused to accept my advice regarding webstart).
Dmitri Colebatch
Well, ok, there's javascript, but I think that is blending the two styles
of interface. If there's behaviour running on the client, it can't
precisely be called thin, can it?
Though I might be accused of splitting
hairs here. Many seem to say thin when they really mean broswer-based. The
problem is, if javascript (or whatever javascript alternative you care to
name)isn't present or is disabled, what happens? True
thin clients
wouldn't have client-side behaviours.
But I think your closing thought
perfectly underscores my thinking: Despite well known solution to the
sneakernet problem, folks continue to choose thin vs thick for reasons of
installation, rather than for more credible ones.
One reason of which is
size of data in the pipe.
Given JavaWebStart, folks have the
opportunity to make choices for more relevant reasons, which should in
theory result in greater diversity of interfaces out there.