my AJAX web app experience in the early days of DHTML

Way back in the 2000-2001 time frame I worked for a technology start up in Kirkland, Washington where we were building telematics software systems (computer applications for automotive purposes - navigation, real-time traffic condition updates, email, locality-based marketing, etc.).

I actually pioneered an AJAX approach to devising the user interface for some portions of our embedded application. (Of course at the time I didn't realize it was AJAX as no one had yet invented that marketing buzz term.)

The target device was a prototype AutoPC from Microsoft that ran WinCE, had IE browser control, and XML DOM stuff - very close to their Win32 implementation versions. (Also developed for a prototype device from Yazaki and standard PocketPC handhelds from Casio and Compaq.)

Initially I was trying to create some UI screens using these UI ActiveX controls that Microsoft devised specifically for the AutoPC, but that was all C++/ATL - very tedious, complex, error prone, and going no where fast. This start up company had some superb web developer talent and I thought if I took an approach where I could leverage those folks I'd be on to a more productive, flexible, and better quality result.

The company's flagship embedded application was written in C++ and used GDI for rendering the UI of the visual navigation portions of the app. Also we already were embedding the IE browser control into this app in order to display some traditional web page stuff downloaded from special automotive-specific web servers. So I decided to build out the rest of the UI of this embedded app in DHTML/JavaScript, XML, and XSLT. (In the end I had to use lex and yacc to create my own mini XSLT and also a mini XML DOM system as the versions provided by Microsoft on WinCE had too huge of a memory foot print - a WinCE process has a 32 MB address space limit.)

Our embedded application had a wireless bi-directional communication data pipe to our server farm - Cellular Digital Packet Data (CDPD). Data transfer messages would be conveyed to the device and the UI would need to dynamically incorporate that data into its visual displays and update accordingly. So data was received asynchronously to various web pages being displayed. JavaScript code then accessed the data and updated piecemeal portions of the displayed web page using XSLT and then DHTML.

This all succeeded and the web designer guy turned out great looking UI stuff in HTML while I did all the nuts and bolts to weave it together and make it actually work within the context of the embedded application. Microsoft and Yazaki went on to show it all off at an automotive electronics show in Detroit. Microsoft had a really cool BMW decked out with their AutoPC while Yazaki had a large booth space where they show cased their telematics console running this app. Oh, the UI was all controlled by touch screen on the Yazaki and voice recognition on the AutoPC. Alas capital dried up in the aftermath of the dotcom crash so I moved on.

So in my current position I have had the experience of building distributed applications in a completely different manner. I have built two significant C# .NET rich client applications that interact with a J2EE middle-tier via JMS (Tibco EMS to be specific). I also built a Java Swing utility app where I became introduced to Java Swing layout managers (the constraint behavior mechanisms for .NET forms are not as powerful). These applications are used in the operations of a number of customer facilities - facilities that are directly tied into the life blood of our national economy's daily ebb and flow.

These apps are a definite contrast to the web-based rich client stuff I designed for the Kirkland start up telematics company. One application in particular is a state machine forms application. Its core manager is a form component hosting system that is rather similar to the Spring framework (at the time I had not yet heard of the Spring framework or dependency injection - I was basing the design off of things I'd learned from working with JBoss mbean services). The experience garnered from this architectural approach has been especially informative relative to the prior rich web app experience. A lot of the same things were accomplished but in entirely different ways.

If I were able to opt for a choice between these two fundamental approaches for devising a new app architecture, I'd go with an approach modeled after this .NET rich client forms app - except using Java Swing and WebStart (so would be platform agnostic and have server-based deployment advantages similar to web applications). With a good forms design tool (Matisse?) I could have UIs created that are every bit as nuanced and attractive as what a talented web designer might do with HTML. And with Swing layout managers underlying the form, it could exhibit much superior runtime adaptive characteristics than HTML web pages or .NET forms.

One of the problems with my "AJAX" web-based app is that even though it was a great improvement at the time over raw C++/ATL/ActiveX-controls, it is still a rather tough way to develop. Whereas devising .NET forms ala the VisualStudio forms designer and using .NET multi-threading coupled to Tibco EMS to get the bi-directional asynchronous data exchange is easier and the overall code is much more understandable (very important for code that has to live a long time).

Building solid web apps via DHTML and JavaScript that has asynchronous behaviors and incremental updating of the UI is hard stuff by relative comparison. I still had to resort to writing a C++ ActiveX control to do some true background multi-threading (which was then accessed by JavaScript). Doing rigorous and robust synchronization on a web page is difficult because nothing about a web browser was designed with this manner of behavior and interaction in mind. Everything has to be hacked and what event notification stuff there is in DHTML for doing some synchronization is rather dismal. Also, the entire conglomeration of the various source code artifacts needed to weave such a solution together is not as understandable and maintainable as, say, the C# code of a form assembly (a Java Swing app would be equivalent in that regard).

Creating AJAX rich web apps is tough even when one can assume the precise browser and operating system that will be used. Yet if one is devising for multiple browsers and perhaps multiple platforms, then that opens a whole other can of worms of problems to solve. With a Java Swing approach there is none of that manner of frustration to be confronted with - well, okay, a little here and there but minor compared to the web app dilemma. (I use the MagicDraw UML tool that is written in Java Swing. It works identically on Windows as it does on my Mac. This is a serious app that has graphical interaction that is rather similar to Visio.)

Where the rubber really meets the road for me, though, is the fact that .NET and Java have multi-threading intrinsically designed into them, it works very well, and synchronization of asynchronous behaviors can be done in a bullet proof manner. Plus the code to do it is entirely understandable and can be augmented by incorporating software engineering tools such as UML, etc. One doesn't get into this completely disjoint world the way web apps do where there is HTML design expertise and then some more traditional programming expertise for devising the server-side business logic stuff. With a Java Swing rich client app approach, what a given team programmer knows applies everywhere.

Another important characteristic of .NET and Java rich client apps vs. rich web apps has to do with memory management. The CLR runtime and Java JVM have sophisticated automatic garbage collection with heap compaction. Because the heap is compacted, it is periodically being restored to pristine condition. Long term heap fragmentation is thus not a factor. The .NET rich client forms app referred to above is constantly adding and removing objects on its local cache yet is capable of running indefinitely. That is exactly what its users do - they leave it up and running 24/7.

The HTML DOM and JavaScript memory management system of web browsers is not as sophisticated. I find both FireFox and IE browser are incapable of running indefinitely - eventually their heaps just get too fragmented and they become sluggish. Because JavaScript in such environments is likely to use a simple reference counting approach (ala Perl prior to the 6.0 rewrite effort), there tends to be more problems with orphaned objects (reference counting is more prone to go awry). So with .NET and Java it's very nice to use a programming technology base that makes it trivial to create applications that can run indefinitely. (The objects that need to be deterministically cleaned up are prominent resources in an app design such that one adds the explicit code to deal with that. After several years of developing with .NET and Java I only experienced orphaned objects when was first learning to work with JDBC drivers. I've been well on guard toward deterministic resources ever since.)

What's really sobering to me about this is that the AJAX rich web app development I did way back in 2000-2001 is very simplistic in comparison to the server-side web app development framework stuff that goes on today. With todays frameworks there are tons of moving parts and interacting technology concepts to learn. Compared to the triviality of my .NET rich client distributed app architecture, it all blows me away what the elite web developers have wrought. And yet in the final analysis a rich client app can still be far more sophisticated in its behavior (most of which is non-visible behind the scenes stuff) than even the most gifted AJAX-style web app. Traditional rich client apps may seem like dumb and old fashioned technology to some but the best rich client apps still surpass the best rich web apps in overall user experience. And frankly, the old-fashioned rich client app really is less difficult to build - despite all of today's conventional wisdom that harps that web pages are brain dead easy and everything should be built as a web page. Every once in a while conventional wisdom is just plain screwy.

Yes, the nature of the Internet tends to pretty much compel a thin client approach. Yet if one is building an intranet distributed application, it is worth pausing and considering if the web app approach is necessarily always the best approach.