Skip to main content

The Rich Web Client conundrum

Posted by johnreynolds on December 7, 2004 at 9:41 AM PST

Rich Web based applications are far from "new", but there still doesn't seem to be a general consensus on how they should be constructed. To the contrary, there are a dizzying array of options for constructing both the client and the server parts of the equation. Perhaps it will help to review the basics...

In reality, there are only three options for implementing the client-side of a Rich Web UI...

Client-UI options:

  1. Construct the UI using Javascript, DHTML and CSS based components
  2. Construct the UI using components provided by a browser plugin (such as the Java plugin or Flex)
  3. Attempt to combine the two approaches using something like LiveConnect (Trust me, this never works)

Options for implementing the server-side of the application have really only two options...

Server-Procesing options:

  1. Process HTTP Posts
  2. Process "custom" data streams or remote method calls (HTTP tunneling, RMI, etc)

I don't believe that this is an over-simplification; you could certainly nuance each option, but essentially these are your choices.

Tapestry, JSF and Echo all use Javascript/DHTML components and process HTTP posts. Each of these frameworks hides the Javascript and DHTML from the programmer, but peek under the covers and that's what you'll find.

Macromedia Flex, Laszlo, Thinlets and plain old Java applets use custom UI components and encourage the use of custom protocols. With these frameworks the line between web-app and traditional network app blurs... maybe that's a good thing, maybe not.

Life can be simpler if you accept this general view of Rich Web Client frameworks... well, perhaps life won't be simpler but your decision making process for choosing your Rich Web Client framework can be.

Your client-side choice boils down to accepting the basic constraints of the ubiquitous browser, or to tie the use of your application to the installation of a third-party plugin (Flex, Java-plugin/Web Start, RealPlayer, etc.) If you really can't live with browser constraints this choice is simple, but most of the time the browser is more of a pain then a true brick wall.

There is one other very important concern before you're done with your client-side choice: What devices will you need to support?

A few years ago, Desktop and Notebook browsers were the only concern, but increasingly PDAs and mobile phones are the devices of choice for accessing Web-based applications. Will your choice of Rich Web Client framework preclude you from supporting these devices?

Your server-side choice has a lot to do with your control over the server: the more esoteric your processing, the fewer hosting options, more firewall concerns, etc. In general I shy away from custom protocols, but if you gotta have it, you gotta have it.

Now comes the bad news. If you pick the wrong approach you're pretty much hosed. There is not a clean migration from the Javascript/DHTML UIs to the richer component UIs. Frameworks like Echo and Tapestry help erase the differences between the browser programming model and traditional component programming models, but if you find that you need a component that cannot be implemented with Javascript, you're out of luck.

So what of the future for Rich Web Client development? Are our choices going to get simpler, or more complicated? Only time will tell.

Update: I came across an excellent discussion by Oliver Steele on Serving Client-Side Applications.

For another perspective, check out this article on Intergrating Macromedia Flex and Java.

Update too:

Since writing this blog entry, there have been several good blogs discussing Google's use of Javascript and DHTML:

Yet another update:
The Echo folks have created Echo2 to incorporate AJaX capable components into their framework.

Related Topics >>