The Thin Client, Thick Client Cycle

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

The Thin Client, Thick Client Cycle


One of the repeated cycles I have seen in my 15+ years in the software industry is that we constantly go through this “thin client / thick client” cycle.
In the 1980s, there was still a lot of software being developed for the mainframe.  These were basically “thin client” applications – most of the processing was done on the server and the model was that of centralized computing with “dumb terminals” acting as the primary interface.  These dumb terminals were indeed pretty dumb (not much processing power, and character-mode interfaces).  But, there were certainly advantages to this centralized model.  The software could be updated on a single server, security was simpler, viruses and other malware were not a big issue.  An important point to note is that these applications were mostly “stateless” (we called it pseudo-conversational in those days).  This allowed a user to believe they were interacting with their application directly, when in fact, 99% of the time, the server was simply waiting for another request and idle users were not consuming any resources.  This particular model allowed a very large volume of users to be served, because not each user consumed server resources (CPU, memory, etc.) when they were not active.
Then, came the “thick client” wave in the form of client-server.  An important thing to note here was that in the client-server model, we did not simply transfer all of the power back to the desktop – but a lot of it.  The reason for this shift to thick-client applications was simple:  There was a lot of horsepower in the PC and it could be leveraged to create better (and more usable) applications.  It seemed a waste to let all that horsepower sit idly around and use the PC as just another dumb terminal.  So, with this shift to client-server, we saw a rethinking of how applications were designed, built and deployed.  The server, in most of these applications was a database server and did notthing more than act as a persistence layer to store and manage data.  Along with the shift came new tools and technologies to help make it easier to build applications for the new paradigm (one that comes to mind is PowerBuilder).
In the late 1990s, we saw again a shift to “thin client”.  Now, this client was a “much smarter dumb terminal” in the form of a web browser.  This trend was fuelled by a number of things:
1.  It was painful to manage desktop applications on hundreds and thousands of desktops
2.  There were classes of applications where the server horse-power and data storage required exceeded the power of most PCs
3.  Internet standards made it relatively easy to build applications that would work across a variety of hardware platforms and operating systems
So, everyone started creating web applications.  Interestingly, and not surprisingly, these web applications too were “stateless”.  So, the web application could serve tens of thousands of users using the same “pseudo-conversational” model made popular in the mainframe days.  Instead of CICS or IMS-DC we now had HTML.  This made the user interface better than the mainframe terminals (we now had color, UI widgets, etc.) but still was a huge step backwards compared to all the progress that was made in the user interface arena in the client-server days.  But, this new thin-client model solved a lot of problems with the thick-client apps.  You could leverage the resources of huge servers, do things you simply couldn’t do on your desktop and had a nice, consistent set of behaviors from hundreds and thousands of applications that were just a browser-click away.
My thesis now is that we are due for another cycle.  Why?  For the same reason we had the prior cycles:  Because there are still problems with the current model.  User interfaces for true “thin client” applications basically suck.  Yes, I know about AJAX and Flex and Laszlo and ActiveX and Java applets and any number of other band-aids that individually could make the user experience much nicer – but the problem is much, much, deeper than that.  The problem goes back to the platform (or lack thereof).  What drives these technology cycles as much as user experience is the developer experience.  If I were looking to reproduce the user experience of even relatively trivial desktop applications today on the web, it’s hard.  Very hard.  Unnecessarily hard.  And, the end result, though orders of magnitude better than a pure thin-client application in terms of user experience, still seems a little fragile to me.  Sure, folks like Google can spend the money to make apps like Google Maps seem like they’re really stable and working.  But, for mere mortals (like me), this is non-trivial.  Technologies like AJAX are non-standard (there are over a dozen ways to do AJAX, each with its own APIs and approach).  Technologies like Flex and Laszlo are too proprietary (even though Laszlo is now open source and supports AJAX).  
So, my theory is that we will see another repeat of history (or at least elements of the historical pattern).  We’ll keep the best of what we have and bring back the best of what we gave up:
  • Nobody wants to go back to the days of updating desktop applications manually on millions of desktops, so the new “rich client” (or smart client or whatever) applications will be self-updating over the Internet.
  • We’ll be able to reuse the component metaphor for UI much like we did back in the old client-server days (sometimes, you simply need a really powerful grid).  We’ll see new UI widgets and vendors that provide these new widgets so a large pool of developers can create really cool apps. In fact, we’re already seeing this movement on platforms like ASP.NET.
  • Next-generation clients will use both a combination of “local storage” and server-side storage (at the option of the user). 
  • Applications will now use the Internet for both data and services

Much of what I’m saying is not particularly controversial (or at least isn’t intended to be).  It just seems to make sense.  There are many of you that will argue that technologies like AJAX will allow us to stay with the current browser-based model and not revert back to a thick client.  Though that’s certainly possible, I think it will be based on how standards evolve and how easy it is for the average developer to build non-trivial applications.  From a startup’s perspective, I’d advise picking platforms and languages that will likely be able to cross-over well if and when the shift back to more of a thick client model again.  
Note:  This article was originally written and posted to my personal site in October, 2005 but has been edited slightly and posted here.

Posted by Dharmesh Shah on Sun, May 28, 2006


Actually, we're already seeing that shift, precisely in the form of "ajax" and other similar solutions. As you noted yourself, the difference between thin and thick clients in where the bulk of computational work is done (or, rather, simply how much work does the client take over), and not where the actual application is located.

What we are seeing is that the client-side applications are now loaded from the server to run in the client, instead to be installed on the client itself. It gives us all the power of a classic thick client, but the maintainability of the thin client. The reason for this is the current availability of broadband access, and is not really than new an idea -- Java Web Start tried that several years ago, but still required some software to be previously installed (JRM).

Actually, even this approach requires some software to be installed (browser), but these days it's extremely difficult to find a PC without some kind of HTTP client installed.

Another advantage of this current "thick in-browser" approach is in the ability to degrade gracefully -- if your system lacks crucial components (e.g. Flash, a recent version of Javascript etc) to run it, a well-designed application can gracefully degrade itself to a standard interface (HTML).

posted on Sunday, May 28, 2006 at 11:58 AM by

There are tons of examples where AJAX alone won't cut it. Take a look at any market that requires higher quality object viewing at the client and a plugin of some sorts is almost always required.

The medical imaging market is the first of such applications that comes to mind. Clinicians can't view radiology studies in a browser that is not able to display the advanced attributes required of the files themselves.

That's one reason why a lot of hospitals use Citrix.

posted on Sunday, May 28, 2006 at 12:19 PM by Raj Bala

That's absolutely correct; however, like thick clients haven't made dumb-terminals disappear, and like thin clients continued to exist after Web became a standard, there will always situations where thick clients will have more sense than any Web-based solution.

posted on Sunday, May 28, 2006 at 12:26 PM by


Isn't *smart client* architecture, by microsoft, serves the purpose as your proposed next generation wave would do ?


posted on Sunday, May 28, 2006 at 1:27 PM by

microsoft's "smart client" is just trying to rip off flash

posted on Sunday, May 28, 2006 at 3:20 PM by mark

Mark: Microsoft's smart client stuff is nothing like Flash. It's basically a set of tools to build self-updating, Internet-connected apps that are more like desktop apps (and don't run within a browser).

Berislav: I agree with your point, but I'm thinking more about the "predominant" model at any given time. Right now, it's thin client whereas 10 years ago, it was thick client.

posted on Sunday, May 28, 2006 at 3:27 PM by

dharmesh i know what microsoft means by a "smart client" thank you very much

microsoft started plugging the architecture just after macromedia started pushing flash as a so-called "rich client" interface. go figure

posted on Sunday, May 28, 2006 at 3:30 PM by mark

I only have one thing to say : the future is already here (but not open source) since 1998 : REBOL. Data is code, and code is data.

The equivalent of .NET in less than a megabyte.

posted on Sunday, May 28, 2006 at 3:49 PM by Jonathan

At any one time there are always apps of the different sorts.

Things improve over time, but it usually seems too slowly.

Maybe what we really need is a truly easy way for developers to weave apps together from, smart, desktop, web... components. (I mean so truly easy that a savvy and determined person, who is not a full time programmers can do a very good (and entirely acceptable) job.)

The history of these systems is deep. I believe MS was looking at the codebase, that is now called Flash, during the blackbird project. Years ago I remember some smart stuff being done with XMLHTTP, now it's called Ajax. It's certainly not new!!

posted on Sunday, May 28, 2006 at 4:51 PM by

When considering mass-scale technological trends (including cyclical, linear, paramteric and nonlinear ones) I believe a large part of the debate is cultural.

When a technology or area of technology touches so many people and affects so many areas of our lives in complex ways (developers' lives and consumers' lives) its reasoning space grows in scale and complexity. Mass-psychology and the psychology of "cults" (how they're formed and how they die off) becomes part of the reasoning space.

Consumer and developer psychologies are not driven by logic alone. Your post could end up being a book if it was to cover the entire reasoning space for cultural phenomena as it applies to thick and thin clients.

The subject requires a much more complex treatment.


posted on Sunday, May 28, 2006 at 10:54 PM by

I think your estimate of what is coming is happening in the form of Adobe's Apollo and Microsoft WPF: i.e. let web apps break out of the web browser

posted on Monday, May 29, 2006 at 3:31 AM by Harry

The browser will not die in the near term. Apollo and WPF will be used in addition to the browser. Diversity is what will happen. the browser model is too culturally deep rooted to be discarded in the short term. The situation is a lot more complex than thin-thick cycle.

posted on Monday, May 29, 2006 at 5:01 AM by

There is so much X/HTML based content and skill that it cannot go.

One logical way to the future is that HTML can contain WPF and vice-versa, allowing a sane shift, and it's all seen via a single interface, the browser!

posted on Monday, May 29, 2006 at 6:43 AM by

"The future has arrived but it's not evenly distributed" is a good answer to this debate. My guess is that there will be a distribution of various technologies, not one grand unifying technology or model. That's what evolution is all about, i.e. diversity... everything emerged from a singl celled organism (or HTML in this case)

posted on Monday, May 29, 2006 at 11:33 AM by

Webstart has been around for a long time. Since Ajax is starting to prove itself as an unreliable and dangerous hack, we're back at thick clients. I couldn't place an order on Dell the other day, because of some stupid live-updating-javascript-html-dom hack, ie, an Ajax(y) type of hack.

Java Webstart is the way to go:
* portable
* sandbox-able, safe, like an applet
* stable
* auto updatable
* proven

posted on Monday, May 29, 2006 at 2:35 PM by Mike

Java Webstart is indeed a great concept, and has only one thing against it -- it's based on Java.

Does anyone know of something similar for Python?

posted on Monday, May 29, 2006 at 3:23 PM by

We've got good examples of language favouritism here.

I'd be very happy with:
1) XHTLHTTP/Ajax capabilities inside the browser and available to any language, and solid
2) Continued improvement of the browser, real improvement not tinkering with the paint job
3) More thorough and dead easy interop, Python, Java, C#, VB.NET, JavaScript (aka C--), Monad...

posted on Monday, May 29, 2006 at 4:26 PM by

I wrote down a few good thoughts about this topic <a href=>here

posted on Monday, May 29, 2006 at 8:51 PM by

well, here then:

posted on Monday, May 29, 2006 at 8:52 PM by

I am thinking about a thick client protocol that is a bit like a media player on steroids. It includes a GUI toolkit that mirrors much of the Windows interface and client-side processing of OpenGL and multi-media streams but definitely NO client-side application code. It can still be processor intensive on the client for rendering multi-media streams. For security reasons, it will normally only connect to a single server where the application runs. It is implemented as a common client shared between all server applications:

posted on Sunday, June 11, 2006 at 3:19 PM by Andrew Robb

plz tell me the difference between thin and thick client web application in

posted on Monday, November 06, 2006 at 11:53 PM by padmini

Dharmesh, have you heard anything new regarding thin client use in the business world or in the military?

posted on Friday, February 16, 2007 at 1:40 AM by Tim

Dear Sir or Madam 
We are Thin Client Manufacturer in China. 
Thin Client is a cost-efficient computer terminal inside which is without processor, harddisk, and RAM, it acts as an agent between server and thin client user, each thin client user work independently while sharing the resource of server, a server supports up to 30 thin client users simultaneously. Comparing to traditional computer, thin client is far more economical and managable, it has been widely used in business, factory, education, hospital and Internet cafe.  
Established in 2003, Kingsem Technology Co., Ltd has been focusing on thin clients and network related software & hardware products which include: Thin client, LCD monitor, Internet/web filter, VOIP, etc. Along with our product line we provide OEM/ODM service to our customers. 500,000 sets yearly productivity makes us the leading thin client company in China. 
Best Regards, 
Kyle Wang 
Sales Manager 
TEL: 0086-020-85898717 
MOB: 0086-13631305590 
35USD for a Thin Client Computer, fairly saving cost for PC access! 

posted on Monday, November 24, 2008 at 3:31 AM by Kyle Wang

Comments have been closed for this article.