Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 221 posts at DZone. You can read more from them at their website. View Full User Profile

Typology of Rich Client Technologies

  • submit to reddit

Chances are, if you are an software architect and need to make applications available over the network, you are asking yourself what client technology to use. In this article, I will try to list the solutions used previously and then elaborate on the solutions available today.


At the beginning, applications were solely deployed on a big machine. Everything happened there. To use the software, you needed to use a poor user interface aptly named a passive terminal. It output text: if you were lucky, you had colors! It was the one tier era.

The next phase started when the cost of  micro-computers went down. Every enterprise wanted to have some. The software industry evolved and moved the applications from the mainframe to the individual computers. It is a move that is still not finished – some companies still have mainframes – but the proof of this is that not many enterprises are migrating from clustered servers to mainframes. Data stayed on the server though: this was the 2-tier era.

Anyway, as software began to flourish on the user’s computer, so did the problems. At first, it was only technical problems: since hard drive space was limited, software vendors toyed with the ability to share libraries among applications. Thus started the infamous DLL hell that sometimes persist today. But the real problems appeared when the number of machines grew exponentially: the deployment of an application on 1′000 or 10′000 computers became a project in itself.

These disadvantages (and the associated growing costs) made some people think lateraly. What if the software was installed on a single node and the user accessed this node through the network? This could solve both the DLL hell and the deployment costs problems. Some devious minds even had the technology to do that just at hand: HTML over HTTP. It was the 3-tier era and we still live in it. Even though you can always add more tier, it doesn’t change the fundamental paradigm.

Limits of the HTML over HTTP model

HTML and HTTP have fundamental flaws for use as an application interface, though. HTML’s real motivation is to navigate through a text document’s maze and HTTP’s only goal is to transmit HTML over the network.

Thus, use of these technologies in ways that were not originally intended now show their limits:

  • browsers are not compatible. That’s sometimes the case not only between two versions of the same browsers but between the same version on two different operating systems
  • the complexity and the costs are transferred from the deployment phase to the development phase. A JEE developer have to know the following stack: Java, Servlet, JSP, HTML, JavaScript and CSS, just to name a few
  • the document centric model of HTTP forces the reload of the entire page, even if just a few elements have changed. The network speed becomes the critical factor
  • users complain about the limited user interactions. Ever tried to filter a combo box in pure HTML?

With the help of Microsoft, AJAX* came to the rescue of the last two problems: AJAX let you update part(s) of the page without a complete reload and give you access to widgets that propose professional user interaction.

Unfortunately, AJAX aggravates the first two problems: what is the support of this new technology among the browsers? Creating the XMLHTTPRequest is a matter or whether the browser is Internet Explorer or not. Even worse, the technology stacks one more component now. You could argue that using an AJAX framework can ease development but the problem stays the same, one more component whatsoever.

For those of you that may think HTML 5 as the panacea, I will respectfully remind you that the HTML 4 specification is dated 1999 and that the HTML 5 specification is still in draft: 10 years in our trade is likely to kill any good idea before its birth. But that’s a post for another time ; back on track, please.


That said, today’s is flooded with plenty of Rich Client technologies aimed at enhancing or replacing our familiar technologies. I will present here only technologies that keep the single point of deployment paradigm (clustering excluded), meaning applications should be able to update (or be updated) quickly and painlessly.

The following picture is a shot at classifying presentation layer technologies in the Java ecosystem. Notice that some may be used in other ecosystems too since they are technology neutral from a server point of view.

Words of advice:

  • this typology tries to dispatch very different technologies into cleanly separate categories. As such, some are more artificial than others. Moreover, some techs may legitimately belong to more than one category
  • don’t hold it against me if your favorite tech isn’t shown above. I have not a complete knowledge of a very moving and innovating landscape

On the right wing, we see technologies that represent a real evolution of the client. They all run over a virtual machine installed on the client computer.

From there, the main difference is whether the application is displayed through the browser or directly. The former are still somehow tied to the browser, such as Java Applets**, Flex that use the Flash plugin or even Firefox plugins. Each of them has a standalone equivalent.

The latter represent a new frame of mind where applications are clearly distinct from sites and are available separately from the tool used to browse sites. Apart from Air that is inspired by the JVM but with higher level considerations, two technologies are worth noting:

  • The JNLP file format, which is an external deployment descriptor available on the web for any Java application. Implementations include Java Web Start, Sun’s solution and an OpenSource alternative which is no more maintained, NetX. Both have the ability to read the JNLP in order to download, deploy and run the described application. They both use the JVM
  • Eclipse Rich Client Platform, which is a basis to create applications upon. Such applications can have the ability to update themselves virtually for free: only declarative use of such a feature is needed. Eclipse RCP also uses a JVM to run

On the left wing, we have technologies that want to enhance the current HTTP – HTML – DOM – ECMAScript – CSS stack. This branch is dependent on the browser’s implementation of the previous technologies specifications, especially ECMAScript. The main subdivision criterion is how the files are generated:

  • the first branch manipulates DOM on the client side. This is the domain of ECMAScript with products such as jQuery, Dojo and others.
  • the second branch creates HTML and JavaScript on the server side at runtime. Those frameworks are nowadays clearly component oriented and such is the realm of JSF
  • the third branch also creates HTML and JavaScript on the server side but at compile time. This is the original approach of GWT

Choice criteria

With all these technologies available, I think now is the right time for an enterprise to consider what rich client tech to use since the HTML paradigm is at an end and there are plenty (too much?) to choose from.

Five or so years ago, when doing Java development, you automatically choosed Struts. Nowadays, the question needs to be asked. But first, what criteria shall be used in order to evaluate the solution(s)? IMHO, these criteria shouldn’t all be technically oriented. The provider or the licence type are equally important because the durability is at the heart of the matter: some IS are built to last with 10 years in mind! The solution chosen will become the company’s standard, so it is a matter of investment and nobody likes wasting money, shareholders even less.

*In the rest of the post, AJAX will be the catchall word for both true AJAX and AJAJ (with JSON instead of XML)
**It it my personal opinion that applets, despite technical drawbacks, were years ahead of their time and for this reason, didn’t catch on. The Apache Pivot project is a framework built upon Applet


Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Milos Silhanek replied on Mon, 2010/01/25 - 4:43am

Why did you ommit NetBeans Platform as rich client?

 I noticed you have worked by Eclipse RPC. So you must know other exist, do not you? Sorry for my comment but list two basic RC platforms is so fundamental.

Nicolas Frankel replied on Mon, 2010/01/25 - 11:33am in response to: Milos Silhanek

What I regard as fundamental is to know one's limitations regarding one's knowledge of a topic. That's why I try never to post an article nor a comment too hastily. I would be grateful if you did the same: please look at my second word of advice...

Jeff Peff replied on Mon, 2010/01/25 - 12:14pm

Nice article. Ya tend to forget that all "tricks" done with HTML can be considered hacks. I mean, making a statefull protocol out of a stateless protocol is clearly showing that the protocol isn't fit for the task in the first place.


I also like your personal oppinion about applets being ahead of their time. I share the same oppinion and even nowadays think they are an excellent RIA platform. I consider JavaFX a re-launch of the applet with a modernized UI.



Milos Silhanek replied on Mon, 2010/01/25 - 2:04pm

I read carefuly including this advice But I decided to note about NetBeans because readers could mislead. 
I am sorry it would not be complete. I am NetBeans fan but under control. Right? 
Good article by my opinion. 

Rogerio Liesenfeld replied on Mon, 2010/01/25 - 5:53pm

It's not correct to say that "HTTP’s only goal is to transmit HTML over the network" or that HTTP follows a "document centric model". Instead, HTTP is a request/response text-oriented protocol, which relies on TCP/IP connections. It's has always been used for much more than HTML pages: images, PDF documents, JavaScript files, CSS files, text and binary files, etc. It's not document centric at all. Even Java/JavaFX applets and applications often use HTTP to communicate with a server.

Daniel Alexiuc replied on Mon, 2010/01/25 - 9:06pm

This is an excellent summary of what is currently available in the web presentation layer.

It stresses me out a bit, because there is no clear, obvious or general purpose solution any more. When choosing any one of these, we are really taking a big gamble that it is going to be around for a while because there are so many other excellent competing technologies.

I think I will tend towards the "Client Sided" presentation technologies in your diagram, simply because I know that they are built on the very basic web technologies that are ubiquitous and will be around for a while yet. Also, server generated client side code somehow just feels wrong to me - it seems like a perversion that everybody has somehow gotten used to.

However choosing the other layers in the stack to go with the client side presentation technology (Service, Persistence, etc) is also not an easy task.

Philippe Lhoste replied on Tue, 2010/01/26 - 5:34am

You have disclaimed about holes in your diagram, but I still find strange to omit JavaFX from this article. +1 for mentionning Apache Pivot, though. I suppose Silverlight is out because it is not part of the "Java ecosystem".

Nicolas Frankel replied on Tue, 2010/01/26 - 6:02am in response to: Philippe Lhoste

My personal opinion is that JavaFX is stillborn: too late for the market. Java Pivot I only heard in the last weeks, even though it is very new, it uses old techs (applets). I thought about including Silverlight though, but in the end decided against it though it can be a nice facade over JEE back ends: call it guts instinct...

Julian Rivera Pineda replied on Tue, 2010/01/26 - 10:16am

Netbeans RCP Platform Matters!!!

Julian Rivera Pineda replied on Tue, 2010/01/26 - 10:18am

Netbeans and Eclipse RCP Platforms are the most important platforms for Richclient over the network, I had tested both and the conclusion is productivity.

Rogerio Liesenfeld replied on Tue, 2010/01/26 - 10:42am in response to: Nicolas Frankel

I think that if Flex and Silverlight can still succeed (and I don't see they having huge acceptance just yet), than JavaFX also can. That, of course, assuming that JavaFX development continues at the current pace, with version 1.3 released in a couple months and 1.4 by the end of the year. Flex and Silverlight are more mature right now, but JavaFX has the advantage (IMO) of a more sound and modern declarative language (ie, JavaFX Script versus MXML and XAML).

Nicolas Frankel replied on Tue, 2010/01/26 - 10:46am in response to: Julian Rivera Pineda

Seems we had different experiences ;-) The term productivity just seems so strange for me in this context...

Julio Argüello replied on Wed, 2010/01/27 - 5:13am

I miss Spring RCP in your list.

 I have quite experience with it: at the beginning it's hard but later everything becomes easier.

In my opinon the product is stable but not really ended! However other opensource efforts (branches) are starting to appear.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.