For some time now, I’ve wanted to update everyone on Fluid’s recommendations regarding JavaScript toolkits. We’ve done a lot of research and evaluation of various open source products, and have chosen jQuery as our favoured toolkit. We think the accessibility plugins and utilities we’ve been writing with jQuery will be useful to a wide range of client-side developers. We’re working closely with the jQuery UI team and the rest of the community to help infuse jQuery UI with keyboard navigation, ARIA roles, and other accessibility features. We’re really excited about this collaboration and for the prospect of another accessible and usable DHTML toolkit, and we hope you’ll get involved.

Why Use a JavaScript Toolkit at All?

Quite simply: browser incompatibilities. There are other reasons to use a toolkit, but the foremost among these is the need to work around inconsistencies and bugs across browsers. Despite attempts at defining standards for JavaScript and the Document Object Model (DOM), there are still major differences in the way browsers handle basic constructs such as events, AJAX connections, and style sheets.

Anyone who writes a lot of JavaScript code without a toolkit will end up with an accumulation of workarounds and object detection checks that will eventually amount to a home-grown toolkit. Writing your own cross-browser code usually starts out easily enough, but eventually bogs down in a maze of subtle and obscure workarounds. Most good JavaScript programmers have internalized these incompatibilities over time, but this knowledge is painfully acquired through time-consuming, frustrating debugging sessions. Take a look at Quirks Mode for all the gory details about browser incompatibilities. The bottom line for me: it’s crazy not to use a JavaScript toolkit.

The decision boils down to cost. Do I want to pay for the all development, maintenance, and testing of an entire JavaScript toolkit? Or do I want to share that cost, and the hard expertise that goes into it, with thousands of other users of a toolkit like jQuery? For Fluid, our priority is to build great user interfaces, not to bang our heads against browser incompatibilities all day. So we knew we had to choose a toolkit.

Evaluating Toolkits

Picking a JavaScript toolkit can be pretty bewildering. The Web 2.0 scene is littered with options, each with very different features, philosophies, and licenses. It’s analogous to the mess we have on the server side with Java presentation frameworks. Superficially, a wide variety of choice seems like a good thing. But practically, we have a plethora of overlapping, inconsistent options that largely do the same thing. To further complicate matters, the client-side UI world is still in its infancy, so this degree of choice and fragmentation ends up leading to a lot of bugs and incomplete features.

Early on in the project, we came up with a set of criteria for evaluating DHTML toolkits. These included:

• Cross-browser support
• Easy debugging
• Event abstraction
• A solid DOM manipulation library
• A strong community and clear roadmap for improvements
• Accessibility

Accessibility is a particularly challenging issue for toolkits, opening up a whole new can of worms for Web developers. The ugly reality is that the vast majority of widgets are completely inaccessible to users who can’t use the mouse or who require an assistive technology such as a screen reader. Worse yet, the standards and techniques for DHTML accessibility are still being worked out, and browser support is significantly in flux.

We’ve been involved in the Dojo community for over a year now, assisting with their efforts to make many of the Dijit widgets more accessible. This work includes keyboard navigation, ARIA semantics, and high-contrast styling. The whole team has done a first-rate job on Dijit accessibility, and continue to make excellent progress.

Many of you might remember our initial efforts to use Dojo as the toolkit of choice for Fluid. We built the Reorderer as a Dijit Widget, and used their drag and drop library extensively. Problems ensued. Some were entirely situational; the Dojo community was pushing hard for their 1.0 release and weren’t able to give as much attention to their drag and drop library as we would have liked. Others were architectural; our unobtrusive, markup-driven approach just didn’t fit well with Dojo’s more “JSF-ish” style of widget encapsulation. We genuinely hoped to leverage Dojo for Fluid, but ultimately realized that it just wasn’t aligned with our needs.

With a broken Reorderer and a release deadline looming, we decided to switch. In a week-long sprint, we implemented the Reorderer’s core using YUI, Ext, jQuery, and MochiKit. We were never able to do a full “apples-to-apples” comparison, but we got a pretty good feeling for each toolkit’s various strengths and weaknesses even though we had to choose quickly. YUI’s documentation was exceptionally thorough, and its feature set was excellent. MochiKit provided a nice clean library. Dojo widgets had great built-in accessibility. But ultimately, we chose jQuery because it just fit.

jQuery Just Fits

jQuery is a pretty remarkable API to work with because it was built with the skills of Web developers in mind. It leverages familiar Web design/development techniques such as CSS selectors, so it’s easy to apply the things you already know and get started with it quickly. John Resig, jQuery’s creator, frequently describes how non-coders are attracted to jQuery because it fits with their “user mental model” as a Web developer. And at the same time, it seamlessly encourages the use of good practices such as unobtrusive JavaScript and functional programming.

jQuery has a very small and focussed feature set. I’ll spare you the usual byte-for-byte comparisons, but it is tiny and carefully organized. jQuery is designed specifically to make the common, tedious tasks of DHTML development faster, easier, and more succinct. If you’ve done any JavaScript programming, you’ll know that the vast majority of time is spent finding things in the document and doing stuff with them. Recognizing this, jQuery optimizes the process of searching for elements in the DOM and performing repetitive actions on them. With jQuery, binding event handlers or applying styling to a set of elements becomes a trivial, one-line exercise without the need for verbose loops. A code example is probably the best way to illustrate this point.

Unlike other toolkits, jQuery doesn’t bother with features such as class-based inheritance or other abstractions on top of JavaScript, and the end result is much cleaner and more comprehensible. After the switch to jQuery, our code base got much smaller. Its selectors and chainability encourage terseness in a good way; code that is minimal but clear and well-named.

I also like the fact that jQuery specifically makes it easier to keep your code and markup separate so that they can be changed independently. The browser environment makes separating logic from presentation feasible, and jQuery encourages this by providing quick ways to grab elements in the document and bind handlers to them when the page first loads. jQuery’s UI widgets are built in such a way that it’s easy to support progressive enhancement, allowing your pages to to be built on a bed of valid semantic markup which will degrade gracefully on older browsers, mobile devices, and so on. Here’s an example of how jQuery UI Tabs take advantage of progressive enhancement.

For features that don’t readily fit within jQuery’s compact core distribution, a “plugin” architecture is provided. I’m using quotes here, since jQuery plugins are written using a simple set of techniques that are based on JavaScript’s prototypal inheritance. There’s no special API here; if you already know how to extend objects in JavaScript, you’ll find jQuery plugins simple to write. A rich set of programming utilities and user interfaces have been released as jQuery plugins by members of the community. I still have reservations about whether the jQuery plugin model is workable in all scenarios. I expect that there will be types of services and components that don’t naturally fit within the jQuery selection-based model.

I mentioned the community earlier. The jQuery lists are healthy and active, and there’s a general sense of openness and welcoming from the group. I gather that, in the early days, John Resig took a lot of time out of his day to patiently answer questions, and this has clearly fostered a generous user culture.

How You Can Benefit From Our Commitment to jQuery

We think that a healthy, open Web should include more than one accessible DHTML toolkit. The Mozilla Foundation agrees with us, and have kindly offered us some funding to help mentor the jQuery community on accessibility issues. We’ll help ensure that the jQuery widget set is accessible, and that there are simple tools available to make third-party jQuery plugins accessible.

Fluid is contributing a lot of the code required by DHTML developers to support accessibility in their own widgets and plugins. And other members of the jQuery community are getting involved. We expect a rich set of accessibility and progressive enhancement tools to emerge over the coming months. Many of these accessibility plugins are ready to use now, and we’d love your feedback and suggestions for how we can improve them in the future.

If you’re already using jQuery, Fluid’s components will merge seamlessly with your existing code. Over time, we’re planning to build jQuery plugin interfaces for many of our components, providing a quick and idiomatic way of using Fluid components in your pages.

Summing Up

There’s a lot of exciting action going on in the jQuery and Fluid communities these days. The jQuery UI team is on the cusp of releasing jQuery UI 1.5, which will provide a significant reworking of the widget model and opens the door for accessibility code to be easily shared across widgets. Fluid’s upcoming Infusion 0.3 release is entirely based on jQuery, and we’re already using a pre-release version of their 1.5 drag and drop library with great success. Expect to see upcoming Fluid components incorporate other jQuery UI widgets, and we’ll contributing usability and accessibility advice back to the community.

We recognize that not everyone is going to make the same toolkit decisions we did, so we’ll do our best to ensure that Fluid’s code plays nice with other toolkits.

Oh, and if you live in Toronto and want to contribute to our work, we’re hiring…