This may sound like a dumb question to ask. But I find that Ajax toolkits offer a mixed bag of features not all of which are necessarily related to “asynchronous JavaScript and XML”. Things usually found in a toolkit include – basic I/O support using XMLHttpRequest and/or iframes, client side widgets for partial page updates, server side controls/APIs for partial page updates, eye candy like drag-and-drop, scrollbars, sortable tables, layouts etc, or support for data transfer via JSON, XML etc, or Comet and so on. I feel that when Ajax toolkits come up for discussion, it is difficult to have a meaningful conversation unless there is a clear set of goals and use cases, and which aspects of Ajax toolkits are we talking about.
IMO, Ajax toolkits are just what they are – kits with a mixed set of tools. Here is the list of points that I would consider when addressing the question of toolkit choice (or even rolling out your own).
Basic I/O
Usually at this layer, we are talking about submitting requests using XMLHttpRequest and/or iframes. What a toolkit would probably buy is not having to deal with cross-browser nuances. But as XMLHttpRequest support becomes more consistent across browsers, this task will become more and more trivial. If all you care about is I/O, using a toolkit does not automatically buy you anything.
Client Side APIs for Partial Page Updates
Here toolkits can add some value. Take, for example, submitting a form via an XMLHttpRequest, and doing some DOM changes when a response comes back (the stuff you do when readyState = 4). This is basic, yet mundane. Toolkits like Dojo could take out some of the drudgery involved in this task.
Server Side APIs for Partial Page Updates
Toolkits offering this support make me uncomfortable. These toolkits usually generate some data and script automatically based on the APIs used in your code on the server side. What makes me uncomfortable about these toolkits is the level of abstraction supported. Usually these toolkits start with simple abstractions which look elegent at the beginning, and become leaky when it comes to complex problems requiring control over details. Without getting into specifics, I would ask questions related to caching, cookies, security, and whether the API has support to control these. If your toolkit stands up to these questions, you are in luck.
Another thing to consider is how flexible the APIs are. Questions to ask include – how well does the toolkit support your favorite web development language and framework, how well does it integrate with your existing apps etc.
Data Support
This area includes support for dealing with JSON and XML. Strictly speaking, this area is not related to Ajax itself. There are a number of APIs available (outside Ajax toolkits) to do this work, and Ajax toolkits don’t necessarily offer any value here. Instead of focusing on toolkit support, I would look at the application I am writing, what kinds of data it needs to communicate with the browser, and a schema for the payload across the app.
Widgets and Eye Candy
IMO, these are pre-Ajax (I mean, pre-Google-suggest), but took a front-seat with the increased popularity of Ajax over the last couple of years. Most of the support here has to do with cross-browser HTML, CSS, and JavaScript to provide some rich UI. Again, none of these widgets may be related to Ajax directly. Most server-side web developers would consider writing these widgets yucky (more about these feelings in another post), and Ajax toolkits may be your best bet.
So-Called Backbutton and History Solutions
As I discussed in a previous post, the problems are hard and the solutions are premature. I would not focus on these features yet, since solutions don’t worky very well. Moreover, getting these solutions to work in complex apps is not trivial.
How About Comet?
Although Comet and Ajax are discussed together often, IMO, Comet is whole different area mostly dealing with web/application servers, and programming models to take advantage of Comet. The problem is to be able to serve responses over long-running connnections without necessarily tieing each connection to a single process or thread. See my post on server push for a demo and some analysis.
In the JEE world, the challenge is to improve the servlet API such that a servlet can process a given request over multiple threads. This gives the boring servlet API some flexibility to wake up when interesting events occur, and generate some more response. Jetty and Glassfish have some experimental (read – non-standard and non-portable) support for Comet. This area will remain in flux until the servlet EG takes up this problem and designs an API. Once this is in place, the next challenge to get servlet containers actually take advantage of Comet and offer scalable support without necessarily tieing requests to threads.
So, what is an Ajax toolkit, and which one to pick? Before asking around, I would list my goals and use cases first. I would also consider the fact there are still too many toolkits, and it is likely that some of these will disappear or get consolidated over time. Other questions I have not addressed here, yet may be important, are how stable a given toolkit is, whether the toolkit cares about backward-compatibility or not, whether a new version of a browser will force you to upgrade your toolkit, etc.
{ 2 comments… read them below or add one }
How stable and how **tested** (cross browser of course) a toolkit is is what matter.
How stable and how **tested** (cross browser of course) :-) is fundamental.