Fog Creek Software
Discussion Board




The misnomer "thin clients"

In one of the threads previously, a poster commented that blogs are being relegated to nothing more than RSS links, with the web browser becoming "irrelevant" (ignore the fact that RSS is nothing more than an index to...web pages, and all RSS readers either embed or are embedded within the browser). This piqued my interest because it touches upon the classic issue of what a "thin" versus a "rich" client is. I think a lot of confusion lies in the belief that a thin client is minimally featured, when in reality it's the thin protocol that is unencumbered and platform independent, not the application itself. It's especially questionable as a title as the layout of HTML, for instance, is tremendously complex, and requires an extremely rich client application.

As an example, and I'm rehashing what I said previously, Joel commented that a web app doesn't have fancy spell checking, yet I see absolutely no reason whatsoever that one could standardize a "SPELLCHECK" attribute of the TEXTAREA element, and "thin clients" could enable full featured spell checking. I see no reason why, after careful  consideration and agreement, one couldn't define an element such as <DROPDOWNMENU><MENUHEAD>File</MENUHEAD> <MENUITEM>Open... and so on (see XUL). HTML, or "thin client" standards, is not static.

Having said all of that...what do you define as a thin client?

Dennis Forbes
Thursday, June 17, 2004

it's always been my understanding that how "rich" or "thin" a client is relates to how close it is to the hardware doing the "hard thinking".  If the server is doing the hard thinking (for example, a web-based accounting program), then your browser is a thin client.  If you're doing the hard thinking locally, then it's a rich client.

But I could be misled.

eaw
Thursday, June 17, 2004

"Close to the hardware" is interesting, but I'd say the portion of the program that contains the business or domain logic is where the guts are.  Some of the logic might be done *in* a browser (adding up fields dynamically, eg), but the browser itself is just doing what the server tells it to do (through javascript).

Since all of the business logic in a web app comes from the server, the browser is thin.  If it does spell-checking, that's a nice feature, but isn't specific to the domain of the app.

pickle
Thursday, June 17, 2004

Over-abstracting. Here, I'll simplify what EVERYONE ELSE (not over abstracting) means when they use thin/thick:

Thin = HTML
Thick = (rest)

Enjoy.

Anon
Thursday, June 17, 2004

Actually, I think it's nice that the line between thick and thin is finally starting to blur a bit.  Why choose between them when you can have the best of both?

For example, in which category would you place a MS.NET No-Touch Deployed application?  You launch it directly from a URL and it relies on server-based (potentially heavy-weight) business logic and data storage, but it processes locally, can fully utilize client-side resources, and can even run disconnected...hmmm.... 

Web services and WinForms/.NET are of course just a new face on the old client-server or  n-tier model, but they enable (or ease) some interesting possibilities.  There's a lot of computing power out there, both on desktops and servers, and it makes sense to take advantage of both.

I think a more questionable use of terminology is the way that "rich client" seems to be used synonomously with "thick client."  As Dennis touched on above, web-based interfaces *can* be rich and full-featured.  Client-side apps can also be clunky, inconsisitent, and unintuitive.  It's all about the designers skills, not the deployment method.

Joe
Thursday, June 17, 2004

For whatever it's worth, we (rightly or wrongly) classify things like RDP (Remote Desktop Protocol) -- Windows Terminal Services, Citrix et al  -- we classify them as "thin clients".

You get the benefits of the "thin" world -- in that it's a minimal client install/configuration, and the benefits of the "rich" client in that you can develop with your normal "rich client" tools, it just runs on the app server, not the desktop. The only thing on the desktop is the RDP client.

FYI -- we've been doing most of our development this way for about the last 3 years or so. It makes deployment of desktop apps orders of magnitude simpler.

There's a whole world out there besides HTML and the internet. Some of us have to work there to make a living.

Sgt. Sausage
Thursday, June 17, 2004

Fair enough, Joe, good point about the distinction between "rich" and "thick."

But getting back to Joel's article, he sees apps with "thin clients" as a threat to MS because the thin client is simple and generic enough to have an implementation on pretty much any os.  E.g., telnet would be another thin client, albeit much suckier.

Hence, the "thickness" is where the app-specific logic is?

pickle
Thursday, June 17, 2004

I think Joel's argument is a good one, and exactly the reason we don't have more rich-client features available for browser-based apps.  If MS adds something useful to IE, chances are it will pop up in other non-Windows-specific browsers too.

It's hard to create a definition based on the thickness of the various layers of an app, because they all have different purposes.  Comparing server work to client work is a bit like apples to oranges.  The server may do things like distributing and enforcing business logic, integrate services from multiple disparate systems, and provide the heavy-weight comms/storage facilities (w/ messaging, transactions, concurrency, load and availability considerations, etc).  But the client can now do other things like processing input, transforming information into different views on the fly, and integrating with other software on the user's machine. 

In a traditional thin-client world, all that work would be performed on the server, or not at all.  But in a standard thick-client world, the server has tended to be more of a data consolidation facility than anything else for most applications.  There was a lot more black and white.

Today's technology choices are really enabling power to be distributed across *all* the layers of an n-tier architecture, so it becomes much less important whether your UI is HTML or WinForms, and more about what you can actually do with it.

Joe
Thursday, June 17, 2004

> <DROPDOWNMENU><MENUHEAD>File</MENUHEAD>
> <MENUITEM>

Did you know HTML 4 actually has provision for cascading drop down (select) menus? It's just that few browsers seem to have implemented that feature:  http://www.htmlhelp.com/reference/html40/forms/optgroup.html

Matthew Lock
Thursday, June 17, 2004

Wow, very cool. I had no idea that feature existed (works perfectly in Mozilla), and it's the sort of "building on HTML" that we need more of (and which Joel mentioned).

I still don't get why Joel is harping on Spellchecking (or why I'm harping against it) - spelling is a system service. I don't want my client hitting a server to determine every word's correctness, given the absolutely commodity nature of spell checking (check out NetSpell with the OpenOffice open license dictionaries). The only possible reason for centralizing the functionality of spell checking would be for user custom words, allowing the user to use their custom words everywhere, but otherwise it sounds akin to centralizing page rendering.

Dennis Forbes
Thursday, June 17, 2004

Spell checking would be better served as a browser feature of a text area. I believe some browsers already have this feature.

Matthew Lock
Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home