AJAX: another wax and polish for your browser?

Sun released Java Studio 2 yesterday, their Java IDE based on Netbeans 4.1. As well as the usual Java editors, wizards, GUI builders, they added support for building AJAX (Asynchronous Javascript and XML) type web applications.

News.com has an article today commenting on the fact that the tools vendors are currently tripping over themselves to rush out products to support AJAX web application development. IBM have a proposal for the ‘AJAX Toolkit Framework’ for Eclipse, so expect to see AJAX support in Eclipse some time soon.

The concept of AJAX is nothing new, it has just attracted a lot of attention recently as the next new thing. I’ve seen AJAX type functionality on websites for a number of years. I worked on several prototypes for functionality for a web based product in around 1999/2000 that used asynchronous messaging and data retrieval in the browser. One approach was a Java applet in the web page that used JMS to subscribe to a Topic, so that the user of the page could receive instant notifications from the application and have them appear in the page, without having to refresh the current page.

The second approach I worked on was the hidden frame type solution. The main page has some Javascript triggered on events in the page to call functions in the hidden frame. THe hidden frame can submit itself back to the server and retreive data which when loaded can then be displayed by the main page. We used this feature to implement ‘dependent dropdowns’ (where data in one dropdown is dependent on the selection in a first dropdown) on pages without having the main page submit and refresh.

The problem with all these approaches is that this type of user interaction was easy to implement with Client/Server type applications. It is easy to implement with fat-client desktop apps. The web browser is none of these things, and yet we’re bending over backwards trying to make it appear to the user as if it is a desktop client/server application. Despite all the promises and benefits of web-based applications, we’re trying to make our web apps behave as it they are not web apps. Seems kind of ironic?

I think we are close to seeing another shift in application deployment topology; I think we’re coming to the end of the web-based ‘thin’ client era. Yes, we’re currently struggling to make the ‘rich client’ approach work with the limitations of current features of the thin client (ie the browswer), but this can only go so far. I think we will start to see an increase in thick-client desktop applications again, because, and lets be honest, if the client is looking for a rich, compelling user experience, then this is a whole lot easier to implement using thick client, desktop based applications that it is with the current features available in browsers.

Yes, we know there are limitations to deploying desktop based applications (version control, distribution and installation), but this is something that can be improved. Java Web Start goes a long way to reduce these issues, and is a much underused and under appreciated technology in my opinion.

So, yes, rich client is currently the ‘big thing’ for web application development, but let me let you into a secret – we used to do that years ago with desktop/thick client type apps… and its a whole lot easier than it is in the browser.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.