ot so long ago, developers had to work directly with the XMLHTTPRequest object or use some very rudimentary libraries to get any AJAX work done. When I wrote my first article about AJAX on DevX in June of 2005, the technology was still in its infancy. Today, at least a dozen freely available AJAX frameworks offer features that can help developers accomplish even the most complicated tasks.

For this article, I tested how well the most popular non-commercial AJAX frameworks performed during the development of a dynamic call-center application. I put each of the following products through the development scenario:

• Prototype
• Dojo
• Direct Web Remoting (DWR)
• Yahoo! User Interface (YUI) Toolkit
• Google Web Toolkit (GWT)

This article presents my findings and reveals what developers should expect from working with each framework.

The Test Scenario
Traditionally, customer support applications are implemented as either thick clients or Web applications with some in-browser dynamic executables. The nature of customer support requires almost instant responses from the application, as well as a number of interactive features that enable diverse lookups for effective responses to customer demands.

These requirements make typical, non-dynamic Web applications unsatisfactory solutions.

The test application for this article is a very simplified call center application capable of servicing customer calls in real time. The most challenging and interesting aspect of the application is its integration with a corporate PBX and account management system (a Web-accessible simulator), which provide near-instant access to information about the caller and his/hers account.

The development and test environment for the application consisted of the following:

• For development, Eclipse IDE, Visual Web Developer 2005 Express Edition (for Web design) and PSPad
• To host the back end, Apache Tomcat 5.5 Servlet/JSP Container
• For browser testing, Firefox 1.5 and Internet Explorer (IE) 6, and IE 7

Figure 1. Call Center Application UI

The call center application’s interface has two main sub-panels (see Figure 1):

1. On the left side, it displays the number of callers waiting to be answered.
2. On the right side, it shows a dynamically populated display of the callers’ information.

The account management system dynamically populates the right-hand panel with caller information as the customer service representative clicks on each caller waiting to be serviced. By displaying this information, the application enables the representative to greet the caller by name, as well as prioritize which call to answer first based on the information provided.

Prototype’s JavaScript Nature
Prototype is one of the most popular AJAX frameworks around. Looking at the results of the Ajaxian.com 2006 Survey on the popularity of AJAX frameworks, one cannot help but wonder why such a small framework is leading other far more developed AJAX frameworks such as Yahoo! User Interface, Google Web Toolkit, and Atlas.

The answer is simple: Prototype feels like a natural, object-oriented extension to JavaScript itself. After working with this framework, I am almost convinced that Prototype should be integrated into the JavaScript language.

For the scenario at hand, Prototype’s small yet powerful and well designed framework proved to be a good match. I completed the first challenge, establishing two simultaneous calls to server resources (for PBX and account lookups), using the Ajax.Request object. The Ajax.Request object is a cross-browser abstraction over the XMLHTTPRequest object. It allows for default as well as asynchronous calls to the server. Furthermore, Ajax.Request accepts the name of the callback function that will be used as the call completes.

So I accomplished the two calls to the PBX system using the following two consecutive calls:

 function getInfo()    {      //load params from form        var callerNum = $F('callerNum');        var url = 'http:///ServiceProvider/pbxService';        var pars = 'callerNum=' + callerNum;                //asynchronous calls are used as default            var response = new Ajax.Request( url, { method: 'get', parameters: pars onComplete: showPBXResponse });        var callerName = response.responseText ;        var url = 'http:///ServiceProvider/acctService';        var pars = 'callerName=' + callerName;        var acctResponse = new Ajax.Request( url, { method: 'get', parameters: pars onComplete: showAcctResponse });    }        //callback functions    function showPBXResponse(requestResults)    {        //show returned value in the PBX area        $('pbxResult').value = requestResults.responseText ;    }        function showAcctResponse(requestResults)    ...

I completed the rest of the scenario using regular JavaScript. Prototype did not play a very significant role in custom rendering of presentation elements. I used it as an event-based addition to regular XHTML/CSS-based UI design.

Dojo?The Wonderful World of Widgets
Dojo is a popular, complete open source framework with broad support not only for Web widgets but also other important aspects of Web application development such as interaction with backend systems. Within its hierarchy of widgets, some (such as Layouts and Containers) were useful out of the box for rendering the callers list (although documentation on many of these is missing from the Dojo manual), while others (such as the multi-select list that makes asynchronous calls) had to be customized.

The customization process exposed me to the world of Dojo widget customization, which required some work with and learning of Dojo internals. While Dojo is very flexible in terms of customization, you need to be very well versed with JavaScript and knowledgeable about the many details of the framework itself. The customization possibilities are limitless; it just takes a while to get up to speed with Dojo.

For the implementation of multiple asynchronous calls to the backend, I used Dojo’s Bind object (dojo.io.bind). The Bind object allows for asynchronous invocation of backend resources and feeding of results into a callback object. For example, the following code accomplishes a call to the PBX exchange:

var getURL = 'http:///ServiceProvider/acctService?callerName=' + callerName;dojo.io.bind({    url: getURL, /* URL to be called */    load: function(type, data, evt){    /* normal callback code here     */ },    error: function(type, error){    /* error handling callback defined here    */ },    mimetype: "text/plain"}); 

While I found navigating Dojo’s widget classes and extension model somewhat involved, its Bind and Callback object models were very natural, easy to work with, and performed well.

DWR?Server-Side Integration Sensation
DWR (Direct Web Remoting) is by nature a different framework from the ones previously reviewed. First, DWR’s focus is making browser client/server interaction as simple and natural as possible. Therefore, most of its API is dedicated to client/server interaction. Second, DWR is a Java-based framework, and as such, it is best suited for applications that run Java on the back end.

Because of these properties, DWR offers a very interesting proposition for developing the call-center application. Instead of having AJAX manipulate a text-formatted response from the server, I utilized the DWR asynchronous remote object invocation from JavaScript. I simply represented and invoked the PBX and accounting Java objects on the server from the browser’s JavaScript. This provided for a very elegant and concise implementation of the AJAX client’s interaction with the server.

In Java, I defined a PBXService object that provides results from a PBX based on the caller’s number:

public class PBXService {    public String getCallerName(int callerNumber){    ...    }}

In HTML, I imported DWR’s JavaScript representation of PBXService and the DWR engine:

...

I called PBXService from JavaScript as follows:

PBXService.getCallerName(18003456700, processPBXResponse);

The custom-defined JavaScript method processPBXResponse processes the results from the call to getCallerName on PBXService.

Although not really as elaborate as Dojo or as JavaScript-ingrained as Prototype, DWR offers very attractive server-side integration. For elaborate integration with server-side Java applications, DWR was the best.

Yahoo UI (YUI) Toolkit?Ready for Prime Time
YUI is an extremely rich, well documented, stable, and lush framework for AJAX-based development. Of all the frameworks I used to develop the sample application, it is the one with the most professional feel.

A complete call center application with all the specified?and some unspecified?bells and whistles was easy to implement using Yahoo widgets and connectors. I modeled the presentation aspects, specifically lists and panels, using YUI’s Panel and Dialog components. I established asynchronous calls to the backend PBX and account lookup systems with Yahoo ConnectorManager and the familiar callback API, as follows:

var pbxURL = 'http:///ServiceProvider/acctService?callerName=' + callerName;

PbxCallback is a JavaScript object defined as follows:

var requestFromPBX = YAHOO.util.Connect.asyncRequest('GET', pbxUrl, pbxCallback); var callback = {         success:handleSuccess,          failure: handleFailure     argument: { callerName: "N/A" } }; 

HandleSuccess is a regular JavaScript function that the application calls to read the response from the PBX server. It issues another request to the account lookup service using the caller’s name it obtained from the PBX:

var pbxURL = 'http:///ServiceProvider/acctService?callerName=' + callerName;var requestFromAcct = YAHOO.util.Connect.asyncRequest('GET', acctURL, acctCallback); 

Figure 2. YUI’s Yahoo! Branding on Call Center Application Code

So you may wonder, given the many useful features of this framework, does it have any issues? Indeed it does. YUI is a very brand-specific API that makes clear in every way that it is developed by one commercial company. YUI is maintained by a Yahoo! team who control all aspects of its design and implementation and who use it for the development of their own portal product. While the framework is generally free, it effectively brands significant portions of your AJAX-enabled Web application code as a Yahoo! product as well (see Figure 2). Those developers who are used to working with very generic and neutral open source frameworks (such as Prototype or DWR) may have a problem with that.

In general, however, the YUI toolkit is simple and easy to use. After getting familiar with the framework?which is rather large when compared with other frameworks, developing with it is mostly an assembly process: putting together the components you need and making them work together. The framework also is very well documented, and the test application I implemented with it works well. So overall, my experience with it was very positive.

Google Web Toolkit?Java Through and Through
GWT follows a very different development philosophy from the rest of the frameworks. It is a completely Java-based development framework; all of the Web components are written in Java and then compiled into a set of AJAX-enabled Web pages. I personally felt very comfortable with this relatively novel approach because I am an experienced Java programmer. But what if you don’t know or develop in Java, or you need more control over what the Java-to-Web components compiler generates? Then you may be in trouble with GWT. Still, it is very easy to work with, so you could easily pick up the Java skills needed to develop with it.

If you are a Java developer, GWT does an amazingly good job of generating Web content?but with some restrictions. A typical Web developer likes plenty of control over the Web content an application generates, but GWT provides only limited control. For example, in my case I chose to use com.google.gwt.user.client.ui.HorizontalPanel for the page layout. This GWT style of Swing (like its relative positioning) is very convenient for Java developers, and it works very well across the browsers. However, if you really need to fine-tune the presentation, you need to step out of the Java-based content specification and start tweaking the produced layout using style sheets. Although that is a very reasonable technique to use, now you are stepping outside GWT’s prescribed Java-only approach.

A Matter of Preference, Not Performance
All the frameworks I used to develop the sample application share a few common traits: they are all very capable, very good at issuing AJAX requests, and free to use. YUI felt the most complete for common, portal-like Web functionality (nice-looking, dynamic, drag-and-drop). The problem with it is its pure framework nature. It gives you a lot, but I found it constraining?YUI felt like it was built to be used only as is. Conversely, Prototype, a lightweight framework, was the most liberating. It is small and thin, and it allows you to build your own application in any direction you want by providing the core AJAX abstractions with its API.

DWR is a very good framework for Java-based applications that require rich interaction with the server side (with DWR, browser logic can interact directly with the domain model, effectively creating a new type of MVC pattern representation). Its authors are very focused on its sophisticated client/server interaction vision. However, DWR will not help you as much if your focus is more on consumer portal-like applications.

If you are looking for a complete framework that supports all the common AJAX-enabled Web development tasks yet still allows for customizations and low-level coding, you’ll like Dojo. If your forte is mostly Java, you likely will be happy with GWT.

Deciding which of these frameworks to use depends heavily on the type of application you plan to develop as well as on your mentality as a developer.