Moving over to an AJAX approach is not something to be taken lightly and certainly not something to jump into without good planning. That being said, this new approach is something many people, and I include myself in that, are extremely optimistic about and the difficult change required is, in my estimation, worth the risk and difficulties associated. In this entry I discuss our journey at White Wall Web and a log of some of the questions that we have needed to ask. We are currently crystallizing the components of our approach, but I hope this discussion will be helpful nonetheless.

AJAX is one of the latest buzz word phrases on the Internet. Currently numerous frameworks (of varying quality) are being developed as this new use of oldish technologies settles. I also expect that most companies and consultants that have a stake in web development will shortly, if not already, be claiming expertise in AJAX.

But what does an AJAX approach really mean? Does it simply mean a rich experience for the end user, something new embedded in existing scripted code? Is it simply a library or class that allows you to perform http requests asynchronously?

We have been investigating just that question recently and the further we dig the more we realize that an AJAX approach requires, in many respects, a complete overhaul of many of our web development approaches. This is partly because the web as a platform does not enforce strict OOP methods. Although AJAX does not inherently enforce this discipline either, I will briefly explain why it is enforced if scalability is a desired outcome.

AJAX is a more about a new approach than a new technology or new language. So what does an AJAX approach require? A starting point is certainly strong separation of data from presentation. This is enforced by an AJAX approach because of the asynchronous calls made by the JavaScript http requests to the server side objects. This will mean the slimming down of server side scripts, functions and objects for many web software developers (it will for us). It will also mean being disciplined about separating presentation from data objects. The prospect of the negative results on supportability/scalability of an undisciplined data object code base when using an AJAX approach makes that option no real option at all. So a successful AJAX approach requires a disciplined OOP approach.

Another important change is a “transport” data format (XML is the data format inherent in the acronym “AJAX” but JSON is the format embedded in the Ruby on Rails and ASP.NET frameworks). This means communicating presentation between the server and browser using one of these data formats (that is how AJAX achieves browser presentation changes with refreshing).

Then, there is a need to use more JavaScript then most web software developers have been accustomed to using in the past few years in order to achieve successful presentation. This code has to be neat and maturely developed to ensure that it stays manageable as it scales.

The use of pre-developed AJAX libraries is also worth evaluating (ProtoType is widely used. There are also numerous plug-in script libraries that extend ProtoType).

The AJAX approach promises what we have been looking for and expecting for a few years now – the ability to create web applications that allow rich end user experiences similar to desktop applications. This could also solve numerous problems that web software developers have grappled with in the past (for example, browser time outs and “back” button problems as a result of posted data etc.) If done right, this is going to benefit everybody.

If done right.