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
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
Note: This article was originally written and posted to my personal site in October, 2005 but has been edited slightly and posted here.