AJAX: Selecting the Framework that Fits

AJAX frameworks can make software development easier. The hard part is selecting the right framework for the job at hand.


May 01, 2007
URL:http://www.drdobbs.com/web-development/ajax-selecting-the-framework-that-fits/199203087

Andrew is an application architect with T. Rowe Price. Chao Wang is a consultant with Sogeti USA LLC, currently contracted with T. Rowe Price. They can be contacted at [email protected].


In 2006, financial services firm T. Rowe Price envisioned a new release of its company-sponsored retirement plan website. Because thousands of participants accessed the website every hour, the main feature of the new release was to put the most important data at users' fingertips. However, the requirements also clearly stated that performance must not degrade and that additional display components would be added later. In short, a new, compact design presenting more financial information on the same-size homepage had to be created.

Our development team decided that AJAX might solve the real-estate issue. AJAX asynchronously loads web page components without reloading the entire page. This dynamic loading is accomplished via CSS, DHTML, and the XMLHttpRequest or ActiveXObject JavaScript methods. These functions can be used directly, or through AJAX frameworks, which provide ready-to-use widgets that work on most browsers.

Several AJAX frameworks were available, and we had to choose the appropriate one for our project—a process that required a significant amount of research and testing. For instance, our requirements included ongoing support for a variety of browsers and usability that had to be maintained.

We educated ourselves, examined several AJAX libraries, and performed browser and load testing throughout the project. The new AJAX-based retirement-plan website was deployed to production in mid-December 2006. To date, we've received excellent feedback, and we hope you benefit from the process we used to evaluate AJAX libraries and develop our first AJAX-enabled application.

Evaluating AJAX Frameworks

To begin our evaluation process, we selected five open-source AJAX frameworks to evaluate:

Next, we narrowed the frameworks to those that fit seamlessly into our development and deployment environments. The retirement-plan website is powered by a content-management server with IBM's WebSphere Application Server (www-306.ibm.com/software/webservers/appserv/was) to render Java Server Pages. Static files, including JavaScript, stylesheets, and images, are all served by the content-management server.

Among the five AJAX frameworks, Dojo, Prototype/Scriptaculous, and YUI were pure JavaScript libraries and worked well in our environment.

DWR is a Java AJAX framework that dynamically generates JavaScript based on Java classes from the application server. Java methods are called from web pages. Unfortunately, this didn't fit into our content-management server architecture. Because a custom patch was required to make it work with our environment, we decided that DWR wasn't a good fit.

GWT is a Java-based AJAX framework that lets you write front-end UI components using Java, then use the GWT compiler to convert them into HTML and JavaScript files. GWT's programming model also didn't fit well with our development environment because our team was split between UI developers and back-end Java developers. Also, the generated HTML/JavaScript code would be difficult to change if we had browser issues. Finally, building the application with GWT required us to learn new Java APIs—not good, considering our time and budget constraints.

Building the Prototypes

Once we narrowed our field to three pure JavaScript AJAX libraries (Dojo, Prototype/Scriptaculous, and YUI), our next step was to create working prototypes using each of the libraries.

Our primary goal in creating these prototypes was to get hands-on experience with each framework so that we understood how they satisfied our project requirements. A second goal was to have working demos so that we could perform browser and performance tests.

Basically, the new homepage design required two visual components:

Figure 1: Typical hub.

[Click image to view at full size]

Figure 2: Typical Tab Panel.

Because none of the three frameworks contained the exact code for a Hub widget, we had to write custom code. Luckily, Dojo does have a TitlePane widget that can be customized to dynamically load content. Also, we only wanted the icon (not the entire title bar) to trigger the expand and collapse. TitlePanel.js and titlePanel.html (available electronically; see "Resource Center," page 5) are customized Dojo code modules that do this.

For YUI, we initially considered extending the Module object, but ultimately decided not to because of the increase in JavaScript file size and complexity. Again, we wrote a custom Hub object; see Hub_YUI.js (available electronically). Finally, Prototype required an update similar to YUI (see Hub_prototype.js).

Dojo's TabContainer widget was close to what we needed and only required updates to style. However, neither YUI nor Prototype had the exact Tab Panel widget we needed. Consequently, we added JavaScript functions to implement the Tab Panel using the Hub. At this point, we had common code between YUI and Prototype, so the code written to support YUI's Tab Panel also supported the Prototype demo.

Other Issues

AJAX technologies let you asynchronously load XML, JSON, or HTML data on a web page. We chose to load HTML (JSP in our environment) partly because it's the easiest way to get started with AJAX.

In all three prototypes, JavaScript was compressed to reduce download size. We used the Dojo compression tool to create a custom build, which included the specific widgets and dependent code. YUI provides a compressed version of JavaScript files ready for deployment. We compressed our Prototype library using Dojo's compressor tool.

Browser testing is an important aspect of overall testing. We chose to complete browser testing early in the process, before making the final decision about which AJAX library to use. To this end, we partnered with our Help Desk to complete browser testing on each of the three prototype pages. Browser testing included a long list of browsers—IE, Netscape, Firefox, and Safari, among them—for both Windows and Mac. It is worth noting that our list included some browsers not on the approved list for each AJAX library. Eventually, we were able to address every issue encountered during browser testing, and the testing process turned into more of a learning activity.

Performance testing is a key ingredient to website success. Clients come to our website to efficiently achieve some goal, not to explore cool technologies. To measure performance, we used a commercial performance-testing system. We often complete website performance testing when a new release first hits quality assurance. However, for this project, we did early performance testing to help select the appropriate AJAX library.

First, we used the performance-testing system to record a user's path through the target website. We defined the primary path as loading the homepage without opening any tabs or clicking any links. Next, we used the performance-testing system to play back the website navigation using various connection speeds. Finally, the average response times were compared.

The smaller the footprint of the framework used, the less likely performance degradation occurs. The total compressed JavaScript file sizes required by YUI (22K) and Prototype (32K) are significantly smaller than the single custom Dojo JavaScript file, which is about 200K. All three libraries performed well with a high-speed connection; however, the YUI and Prototype/Scriptaculous prototypes performed faster with 56K dial-up connections.

The results of this test gave us a rough idea of how AJAX technology affected site performance. In the end, we were hesitant about using Dojo because of the impact on dial-up users. That said, more recent versions of these libraries may produce different results. Furthermore, our results were affected by our widget choices and compression technique.

Later in the software lifecycle, we repeated both browser and performance testing on the release in our quality-assurance process. Given the earlier work we performed, we were pleased not to run across any browser or performance issues during this final round of testing.

Compare Ease of Development

Throughout the process of building and testing the prototypes using each AJAX framework, we got a good understanding of how to work with each framework and the strengths and weaknesses of each.

Overall, Dojo provides more features and HTML widgets than YUI and Prototype. However, Dojo's widget customization requires some effort. Each widget requires one or more JavaScript files and possibly an HTML template file, images, and a stylesheet. Styles are somewhat tied to the JavaScript and HTML templates. If the template to build the widget is different from the design you were given, it may take some time to customize it. This happened to us when we used the HTML TabContainer widget. None of our Java developers are good at the stylesheet, and we had to turn to our graphic designer to change the default style for the widget to suit our needs. This isn't an issue with YUI or Prototype because their styles are separated from the dynamic behavior of the hub.

As developers, we were also concerned about ease-of-use with each AJAX framework. This is related to how well each framework is documented, whether there are examples that we can quickly try, and how easy it is to understand the source code. All three of our demos stretched our JavaScript expertise. JavaScript knowledge is an important consideration for teams starting their first AJAX implementation.

We took a look at the source code of each framework and felt that YUI is easier to understand because of its well-documented code and detailed tutorials from the Yahoo website. At the time of this development project, both Dojo and Prototype lacked complete documentation and we had to try to build our own prototypes. In the end, YUI stands out as the easiest to work with.

Making the Final Decision

With several criteria in hand, our next task was to decide which AJAX library to use. To ensure an objective decision, we used the decision matrix in Table 1. The criteria included widget availability, maintainability by both UI specialist and Java developer, download size to browser, and documentation. We recommend you make your own list, as your criteria may differ.

Our development team settled on the Yahoo! User Interface Library. And in the long run, our decision worked well for this and other projects.

Criteria Weights (5 to 1) Scores (5 to 1) Weighted Scores
Widget Availability 3 D 5 D 15
    Y 4 Y 12
    P 3 P 9
Ease of Maintenance 4 D 3 D12
    Y 5 Y 20
    P 4 P 16
Download Size to Client 5 D 3 D 15
    Y 5 Y 25
    P 4 P 20
Documentation 4 D 3 D 12
    Y 5 Y 20
    P 3 P 12

Table 1: Decision matrix. Dojo=54, YUI=77, and Prototype=57.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.