Overview of Ajax

Ajax (Asynchronous Javascript And XML) has moved into the limelight with the oncoming of popular online tools like Google Maps, Gmail, new Yahoo Mail, Gtalk (on mail), Flickr and others to name a few which get classified as Web 2.0 applications. Till now people didnt sit up and take notice of Ajax but today all of the top sites have introduced their 2 bits and every known product are looking at Ajax based frameworks in their implementation. In the .Net and Java world too, Ajax has been given significant support and importance moving forward. Ajax is the next best thing to have happened to the web after Web Services. Even better, ajax and webservices combined is one of the most powerful implementation practice put together on the web since dynamic pages came into existence back in the late 90s.

There is a hue and cry about Ajax everywhere on the web. Ajax seminars, conferences, books lining up the computer shelves and thousands of articles. Every top company Microsoft, Oracle, Google are promoting it as the next big thing.

My two bits on ajax would try not to divulge much into ajax coding samples or how it works. It may also not bring to light the vast capabilities or what the future holds for ajax as i still dont have an insight into that. But my emphasis would be more on who should take up the reins on making use of this Ajax cloud in application development and why from a purely development perspective.

If we look at Ajax from a server side developers end, nothing really has changed. He still writes tons of code for application layer and business layer logic. The only thing that has changed is his delivery method. Earlier, where he used to create dynamic pages using objects to store/ extract data and process everything, inlcuing UI elements on the server before sending the html code to the client, with ajax he in inclined to build a data stream (ideally XML - thats why AJAX) with the content of the request and post it back to the client. The developers overhead of building several HTML page code based on various scenarios are also cut down here to some extend. So in essence his work has been reduced. He may but want to implement newer frameworks to support the redesign in interaction between the client and server that has resulted because of the Ajax implementations and approaches. Well what you know, tons of new classes and much more effort as he approaches the ajax implementation challenges. Yet, nothing really new as his base backend architecture will continue to remain the same. So once again his role on a project is critical and is not redundant as we were inclined to believe. But for applications whoes business layer are intact, he only needs to make changes to the UI and Application layer to get Ajax to work.

But the real challenge here as before lies in the hands of the interaction designer. Where his job earlier would have been to develop a couple of screens, set guidelines for further screens and build interaction points, action items, graphical aides and user interaface, he is now entrusted with the job of mapping the entire client facing application from an interaction perspective.

Thus according to me, an interaction engineer should hold the reins of any Ajax implementaion.
I have been designing and developing web based application in a variety of domains on different technologies since 1998.

The real challenge here is not figuring out how to make the code work but thinking of interesting ways in which it can be utilized.