Web Forefront

Attempting to reduce AJAX development pain through a framework can be a daunting task, with well over 30 frameworks -- last count, could be even more the coming month -- offering everything from pre-built GUIs, editors, enhanced security, tight integration to server-side platforms and many more features, selection can be a critical step, especially when you consider all your organizational AJAX projects can be in it for the long-haul with this building block.

Since its probably impossible to make a side by side comparison on every AJAX framework out there, I will go ahead and tell you my rule of thumb for selecting AJAX frameworks: the further it is from a standalone javascript library -- .js file -- the more trouble you will probably get into, case in point, the bigger your AJAX framework download the more cautious you should be about using these magic bullets in your projects.

AJAX started of as pretty much every other emerging technology, as 'voodoo' code made exclusively by developers/programmers, but now that the concept has been grasped by a larger audience, I believe its getting clearer to whom the AJAX reins really belong to : graphic designers and usability experts.

If you look at AJAX applications, they really are just a series of data chunks that get continuously loaded from a server, without the user experiencing a blank screen between loads. The order, layout, size and other such properties behind this data -- which can be considered analogous to classical page navigation issues -- should be left entirely in the best hands, in my opinion, those of graphic designers and usability experts.

Which takes us a little deeper into the thorny AJAX framework selection process: making it usable and understandable to non-programmers. The best AJAX frameworks, make an excellent job of abstracting away the programming complexity of filtering data chunks, requesting information to the server, laying out data and other such issues.

The key point here is that the more heavily-featured an AJAX frameworks is -- especially those that are tied in some way to server-side code -- the more likely it is to loose appeal among the people best prepared to create AJAX applications in the first place. In my experience, the best results I've seen in terms of AJAX developments, have come precisely from using simple AJAX'ed JavaScript libraries like Prototype , JQuery or Scriptaculous and letting the front end people immerse themselves slicing, dicing and laying out the data as they see fit, granted the bar for graphic designers and usability experts may be raised, these AJAX'ed JavaScript libraries ('frameworks') are there to lower the 'voodoo' status to more mundane steps.

Which begs the question, does this mean server-side/enterprise developers should be oblivious to AJAX ? Absolutely not, they actually play an equally important role providing access to all the data chunks that conform AJAX applications. In AJAX's case, these data chunks are access points provided in the form of REST type web services, which is of course what server-side/enterprise developers do best, provide scalable and secure data access.

In the same way server-side/enterprise developers provided all the data 'bread-crumbs' in pre-AJAX applications in tags or templates for graphic designers and usability experts to handle, in AJAX type applications, these data 'bread-crumbs' take the form of REST web services which can later be accessed by graphic designers and usability experts via their favorite AJAX framework.

On a final note, leaving AJAX frameworks out of the server-side equation and concentrating exclusively on RESTfull web services, also has one side-benefit for those in the enterprise space: Service Orientated Architecture. By decoupling AJAX and pushing any type of framework out to the browser as pure JavaScript, the same RESTfull web services used to harness AJAX applications, can also be reused in some other shape or form in the enterprise for applications not just tied to the browser, in effect extending the SOA re-usability principle.