Ajax library smackdown: Dojo versus YUI

Using libraries to create a better user experience

Asynchronous JavaScript and XML (Ajax) is everywhere, from the local newspaper to sites that CEOs surf. Contrary to popular belief, it isn't rocket science, especially with the right library. Explore the popular Yahoo! User Interface (YUI) and Dojo libraries, and learn how they can simplify typical Ajax techniques and make JavaScript easier to work with. Discover why you should use a library in the first place and how to choose among libraries. Get some specific examples from YUI and Dojo, as well.


Nathaniel T. Schutta, Solutions Engineer, ntschutta.com

Photo of Nathaniel SchuttaNathaniel T. Schutta is a senior software engineer focused on making usable applications. A proponent of polyglot programming, Nate has written two books on Ajax and speaks regularly at various No Fluff Just Stuff symposia, universities, Java user groups, and conferences around the world. In addition to his day job, Nate is an adjunct professor at the University of Minnesota, where he teaches students to embrace dynamic languages.

08 June 2010

Also available in Chinese Russian Japanese

Creating a modern web-based application requires more today than it did just a few short years ago. Today, developers are tasked with creating rich, interactive UIs that take advantage of all the techniques in the Ajax toolbox. When these approaches were first introduced, many pundits insisted you needed to be a rocket scientist to pull it off, and while not trivial today, high-quality frameworks have helped the cause. This article looks at how popular libraries like Dojo and the Yahoo! UI Library (YUI) have simplified the life of today's JavaScript developers, why you should use a library in the first place, and how to choose among libraries. It also provides some specific examples from Dojo and YUI, as well.

Why should I use a library?

Back in the paleolithic web era known as the late 1990s, those of us doing client-side development had things pretty rough. Our monitors had lower resolution than today's hippest smart phones; the browser wars were in full swing, giving us a variety of incompatible behaviors; and our toolbox was only slightly better than that guy who insisted on using punch cards. And we walked to work uphill in the snow both ways. Getting JavaScript to work properly across browsers was a Herculean task, and on one early project, I ran into so many issues the manager laid down the "thou shalt use only the bare minimum JavaScript required to make the application work" decree. I do not miss those days.

Things have settled down considerably. But browser issues are still around today (Windows® Internet Explorer® 6, I'm looking in your direction.) In addition to a much-improved toolbox, today you can take advantage of a veritable plethora of libraries to ease the burden of developing cross-browser front-end code. In fact, you face a paradox of choice in your effort to select just the right framework to make your life easier—but that sure beats long nights debugging that intermittent issue with browser X on the Y operating system! Today, you should look to a library to create a baseline for your coding efforts—a virtual machine of sorts sitting between the various browser implementations and the code you're trying to write.

In addition to smoothing out browser differences, toolkits give you additional leverage in your day-to-day coding efforts. Some libraries are minimalists, doing one thing and only one thing, while others are all-encompassing kitchen sink-sized toolkits that seek to rectify shortcomings in all things web. Though each library is different, there are several common themes. Most provide:

  • A wrapper around the XMLHttpRequest (XHR) object
  • Cross-browser CSS selectors
  • Simplified event handling
  • Various animations, effects, and widgets
  • Sundry utility functions

How do you pick one library over another? The only wrong answer is coding everything by hand—not using any library. Picking a library can be difficult, but it's nothing compared to trying to do everything yourself. Before you panic and think you have to choose just one library, know that most them work fine together (within reason), and sometimes mixing and matching is the best option. Regardless, here are some things to consider when picking a library:

  • What do you want out of it? Are you looking for a complete replacement of nearly all UI elements on your page, or are you just looking for something to take a bit of the pain out of JavaScript programming?
  • How easy is the code to read? Despite massive improvements in documentation over the past few years, odds are you will have to dig into the code at some point. Before committing to a library, spend some time knee-deep in the source. Is it easy to understand, or does even the original author have trouble with it?
  • How good is the documentation? Clean and readable code can make up for less-than-stellar documents, but nothing helps you get started quite like tutorials and examples. Poke around the wiki or the website, and see what they have to offer. Are the examples clear and easy to follow? Does a quick Google search bring you to the proper part of their material?
  • What's the community like that surrounds the library? Check out the mailing lists. Is there a lot of traffic? Are new people treated with respect or derision? Has the code been updated recently, or was the last release several years ago?
  • Can you get help? Although this is related to the previous bits about community, it's always valuable to look around the development community and see who's using what. Check out the job boards to get a sense of which libraries are showing up frequently on resumes.

Before making a final decision, be sure to spend some time playing with the finalists. Some libraries have a certain flavor—for instance, Prototype brings a strong dose of Ruby to JavaScript programming. If you think Ruby is the language to end all languages, this is a feature. But if reading Ruby makes your eyes burn, Prototype might not be the best choice. Reading code and following tutorials is fine, but until you actually try to solve some of your pain points in a given library, it's hard to know which one is right for you.

Why YUI and Dojo?

With so many excellent choices at your disposal, why would you consider YUI or Dojo? In a word: completeness. Unlike other solutions that involve additional libraries or plug-ins, Dojo and YUI have everything (and more) that today's front-end engineer could want. While that is both a blessing and a curse, if you're in the market for a one-stop shop for your Ajax needs, these are two powerful contenders. In addition to a wealth of JavaScript helpers and utilities, both offer top-notch widgets and controls—far beyond the limited palette of the standard browser.

YUI and Dojo are actually quite similar. Both offer a strong core of utilities and helper functions, and each has an excellent collection of widgets and components. In addition to the old standbys like calendars, trees, and menus, each has a charting option. You'll find a strong, vibrant community answering questions, fixing bugs, and adding new functions in both camps. They feature excellent websites with example code, references, getting started guides, and—if you prefer the feel of paper—each has books covering these impressive libraries.

The JavaScript language lacks namespaces or packages, something Dojo and YUI overcome in how their code is named and packaged. With YUI, the code lives under YAHOO plus some combination of "package" names. For example, YUI's event utility would look something like this:



YUI version 3 is a relatively new, ground-up rewrite of the Yahoo! library. Designed with performance in mind, this update looks very promising. However, at the time of this article, the widget library is a little lacking, though that should change in the coming months. If you're starting today, you may want to concentrate on YUI version 2 but keep an eye toward the future of YUI 3.

Dojo follows a similar approach, though its implementation is simpler. You access the core using dojo as the top-level wrapper, while the widgets are found under dijit.

Though similar, these two libraries are not identical copies of one another. Dojo allows you to use its widgets either declaratively or programmatically. In other words, you can configure your widgets with special attributes in your mark-up, or you can use standard JavaScript code—and you are always free to mix and match. Dojo has a rather helpful dependency manager; when you require a given module, Dojo makes sure you have everything you need. It also makes sure dependencies are loaded once and only once.

Ajax the easy way

Although the XHR object itself isn't very complicated, there is just enough nuance to doing it right that you'll soon come to appreciate the abstraction layer found in virtually all of today's Ajax libraries. Dojo and YUI are no exceptions, and each provides a simple-to-use wrapper. You'll find common themes when working with XHR using a library. At a minimum, the wrappers will:

  • Provide the URl of the resource to call
  • Provide a way to pass parameters
  • Offer a method of specifying the HTTP method (get, post) to make the call
  • Include a callback technique to handle the result of the call

YUI and Ajax

YUI stashes its XHR wrapper in the Connection Manager. The API is straightforward: You call a singleton method and get back a connection object. A typical call might look something like Listing 1.

Listing 1. A sample YUI Ajax call
var url = "/fooApp/validate";
    var msg_div = document.getElementById("messages");
    var callback =
        success: function(o) { msg_div.innerHTML = o.responseText},
        failure: function(o) { console.debug("An error occurred: ", o);}
    function validate() {
      var form = document.getElementById("pim");
      var transaction = YAHOO.util.Connect.asyncRequest("GET", url, callback);

This may look a bit verbose compared to other libraries, but I've spread things out a bit in the name of readability. You could always put the callback functions and the URL directly into the call to Connect.asyncRequest. As you can see, you retrieve certain elements—here, a <div> that will house the message back from the server—as well as the form that contains the data you want to send to the server. Calling the setForm method on the Connection Manager gathers form values and packages them appropriately based on the type of call you're making (in this case, a GET request.) The asynchronous call to the server will be triggered when the validate method is called.

Dojo and Ajax

Dojo's approach is similar to, though somewhat less verbose than, YUI's. Dojo's XHR wrapper lives in Dojo Base, and it exposes methods for the major HTTP verbs (post, get, put, delete). One way to call it can be found in Listing 2.

Listing 2. A sample Dojo Ajax call
    var xhrParms = {
      url: "/fooApp/validate",
      load: function(response){
        dojo.byId("messages").innerHTML = response;
      error: function(data){
        console.debug("An error occurred: ", data);
      timeout: 2000,
      form: "pim"
    function validate() {

Again, I've chosen to spread the code a bit to improve its readability, but you could place the parameters directly into the call to dojo.xhrGet if you prefer. As you can see, this example is similar to YUI's, with some interesting differences. First, you may have noticed the distinct lack of document.getElementById calls. Getting an element by ID is something that's often done and, well, it's easy to mistype something with more than 20 characters in it! Many libraries provide a shortcut of one form or another, and Dojo gives you dojo.byId. Though not quite as spartan as Prototype's $, it's still a huge improvement. Once again, your call to the server will be invoked when the validate method is called.

The power of CSS selectors

CSS selectors are a powerful tool in the web developer's toolbox, but as with JavaScript itself, browser support isn't universal. Luckily, today's libraries step into the void, giving us the full power of CSS selectors.

YUI and CSS selectors

YUI gives you the full power of CSS version 3 selectors with its Selector utility. Essentially, you create a "query" on a particular CSS selector, and you get back a collection of elements that match that criterion. For example, see Listing 3.

Listing 3. CSS selectors with YUI

  function bindEvents() {
    var headers = YAHOO.util.Selector.query('.header');
    YAHOO.util.Event.on(headers, 'click', toggleSection);

In this case, you're looking for any elements that have the header style, and you then apply an event listener to each element returned (more on that in the next section). As you can see, this is a compact and powerful way to retrieve elements. In this code, the toggleSection method will be called whenever someone clicks an element with the header style.

Dojo and CSS selectors

Dojo has an equally powerful selector mechanism at its disposal. It also calls its implementation query and, as before, you give it a CSS selector and it gives you a collection (see Listing 4).

Listing 4. CSS selectors with Dojo

  function bindEvents() {
      function(header) {
        dojo.connect(header, "click", toggleSection);

You're given every element with the header style, and you then iterate over that collection with the forEach method, applying an event listener to each element.

Event handling

In the era of unobtrusive JavaScript, event handling is especially common. Alas, today's browsers aren't always up to the task, but library designers have taken it upon themselves to simplify our lives once again. In the previous section, you saw two ways of binding to the click event: YUI's Event and Dojo's connect. In both cases, you're asking to be notified when an event occurs so that you can take some action—in these examples, toggling a section (that is, hiding it if visible or making it visible if it's hidden). You could have added event handlers directly to your mark-up, but using an abstraction as you see here is much cleaner, as it separates your business logic from your presentation, making for cleaner mark-up and easier-to-understand code.

You can't attach an event to an element until the element is loaded—but how do you know when that happens? Dojo and YUI give you some helper methods for just this occasion! In YUI's case, you have:


while Dojo gives you:


In either case, you can leverage these helpers to make sure your events attach when the document is ready. There are other ways of accomplishing this task, but few are as easy to understand as these.

Widgets: windows, date pickers, and more

The palette of the modern web design is pretty barren: You've got text boxes, text areas, buttons . . . and, well, not much else. Once again, when the browser lets you down, the library designer picks you up. Today, you have nearly everything available in a rich desktop application: You have date pickers, menus, trees, sliders, windows, and more. It's a veritable cornucopia! Let's take a look at a date picker in YUI and Dojo.

YUI's date picker

YUI provides a very rich set of controls and widgets that you can use to make your applications pop. Entering dates by hand can be error prone, and most users have come to expect some kind of control. YUI has a great date picker that is in the Calendar component (see Listing 5).

Listing 5. A date picker in YUI
    var cal = new YAHOO.widget.Calendar("cal", "cal1Container", {navigator:true});
    var bday = document.getElementById("bday");
    YAHOO.util.Event.addListener(bday, "focus", renderCal);
    function handleSelect(type,args,obj) {
 		var dates = args[0];
		var date = dates[0];
		var year = date[0], month = date[1], day = date[2];

		bday.value = month + "/" + day + "/" + year;
    function renderCal() {
        cal.selectEvent.subscribe(handleSelect, cal, true);

There's a fair amount going on here, but much of it you've seen before. You're creating a calendar widget with your call to YAHOO.widget.Calendar, and you set up a listener on the birthday field, which causes the calendar to appear when it receives focus. The handleSelect puts the value the user selects into the birthday field. This is just the tip of the iceberg, though. The YUI calendar is very configurable, and it also supports internationalization.

Dojo's date picker

Dojo also has a wealth of outstanding widgets—widgets that are designed to be accessible and support internationalization. In this case, take a look at Dojo's declarative programming style; instead of handcrafting several lines of JavaScript code, you can simply add:


to the field you'd like to turn into a date picker. By adding the two lines from Listing 6, you've got yourself a calendar with almost no effort!

Listing 6. A date picker in Dojo

Getting help

Whichever library you prefer, at some point you'll need some help. YUI and Dojo each feature extensive online documentation from full-on tutorials to detailed, step-by-step examples. Each also has many books should you choose to have a physical artifact to paw through, and both have vibrant communities that are eager to answer questions. The best place to start is their respective websites (see Resources for links).


This article covered a lot of ground in a short space, and frankly, it only scratched the surface of what these two outstanding libraries have to offer. If you're not currently using something, I hope I've convinced you to try Dojo or YUI. Each has a passionate and well-deserved following, so play around and see how they can help you deliver a better experience to your users.



Get products and technologies

  • IBM product evaluation versions: Download these versions today and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development
ArticleTitle=Ajax library smackdown: Dojo versus YUI