John Reynolds's Blog

The Rich Web Client conundrum

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.

Comments

• Hi!
  as far as I know, dhtml/javascipt-based clients were called "thin-clients".

  In your categories richclients always have UIs based on components provided by a browser plugin (such as the Java or Flex)

  In your 2nd UI-Option you spoke about "browser plugins".. does this include super-mini browsers (mostly simple a http-processing engine) embedded in network-enabled tools ?
  I think this is, what most people think when talking about richclients ?

  greets, Toni

  Posted by: tonit on December 07, 2004 at 10:17 AM

• Rich Clients vs. Thin Clients
  I think these definitions are a bit fuzzy at best, so I would fall back on what the user experiences. With clever Javascript and DHTML it is quite possible to generate a UI that gives the user a "rich" experience. The user generally has no idea or interest in how you chose to implement your application.
  You bring up a good point with respect to what I am calling "plugins"... there's very little difference between a Java application running in the Java browser plugin or one running via Java Web Start.... both could equally qualify as web-based applications.

  Posted by: johnreynolds on December 07, 2004 at 10:50 AM

• Perhaps I can offer one perspective. Take the ScheduleWorld J2ME cell phone/PDA application. It's a rich calendar client on the cell phone that provides full round-robin capable synchronization and a usable number of iCalendar attributes in under 64KB. The client/server protocol is pure HTTP/XML and leverages the same infrastructure used by the much heavier-weight J2SE Java Web Start client. This means the two can interoperate. The SyncML service also taps into the same infrastructure and increases interoperability as well. IMHO the rich client benefits enjoyed in both environments are huge. F.E. the J2ME client uses asynchronous I/O for all client/server communications. Because I use standard J2ME GUI components and the Canvas I don't have any browser issues and the app looks identical (it's resolution independent) on every device. The future is now. :-)
  

  Posted by: markswanson on December 07, 2004 at 08:42 PM

• The only thing that ever came close to being the ideal rich client architecture for the web is *java applet*. Somehow we decided to ignore it's power.

  
  But java applet has a major problem which eclipses all the good things about it. ? A java applet needs a browser (via java plugin of course) to launch.
  

  Posted by: sutanu on December 09, 2004 at 07:14 AM

• Sutanu, you may want to take a look at the much more powerful Java Web Start rich client architecture.

  Cheers.
  

  Posted by: markswanson on December 09, 2004 at 08:48 AM

• JDNC!
  CHeck out sandrasf.com based on it.
  .V

  Posted by: netsql on December 12, 2004 at 08:58 AM

• You missed ActiveX using tools like ATL.
  With a combination of ATL and HTML/JavaScript and, Yahoo accomplishes many great things. Why ATL? The resulting code is very small. 95% of Yahoo OS market is Win98/NT2000/XP. Based on OS share and a focus on size, ATL makes sense.

  By the way, I have seen huge JavaScript/DHTML/CSS solutions where Java would have been easier to design, construct, and use, as well as much smaller.
  

  Posted by: malcolmdavis on January 05, 2005 at 02:51 PM

• ALso check out http://sandraSF.com - its based on JDNC.

  .V

  Posted by: netsql on January 11, 2005 at 05:22 PM

• I'm trying to fix an applet that I wrote that uses liveconnect. It keeps crashing IE 6, and I have no idea why. I built it without using any real documentation, just an example applet I had the source code to.

  I couldn't really find any good docs online since they all point to a now dead netscape link.

  If anyone could help me, I'd be much obliged.

  Posted by: heaththegreat on January 24, 2005 at 05:17 PM

This work is licensed under a Creative Commons License.