DHTML is what makes the browser dynamic, and JavaScript frameworks allow mere mortals to make it happen.

JavaScript frameworks are the newest weapons in the Web application arsenal, and they're seriously powerful. Comparing something like JQuery to a JavaScript date picker is like comparing a cruise missile to a slingshot. The problem is trying to decide which one is best for you, and that's going to depend a lot on what you want to do. But suffice it to say that if you want a dynamic application, you will need one of these toolkits.

The first frameworks came about specifically to allow more powerful JavaScript programming. Other frameworks are designed primarily to make your applications sexy. The Web 2.0 movement spawned these libraries, and they can do spectacular things visually. Still others have been written to interact with server-side logic. Some are commercial, some are open source, and some are a strange mix of the two (the Google toolkit uses services that Google provides for free--well, today they're free).

Where Did All These Wonderful Toys Come From?

The sheer number of frameworks available makes an exhaustive study of the subject...well, exhausting. Just trying to break the frameworks down into categories is a tough job, because a lot of overlap exists between the various packages.

For example, let's start with something simple like Prototype. While dynamic HTML (DHTML) has been around for a long time, it wasn't until the popularization of AJAX that people really started to look at it. That's because AJAX changes the rules entirely; instead of having to load an entire page to get new data, the browser can make requests back to the server for small chunks of data. This in turn means that the page can react dynamically to user events as small as individual keystrokes or mouse movements.

The driver behind this whole process is the XMLHttpRequest. The function is actually misnamed because it doesn't require XML, but that's not really at issue; the important point is that the code, even for a simple request, quickly gets bogged down into the intricacies of JavaScript and object orientation. Take the simple function below:

function ajax(url, vars, callbackFunction) {

  var request =  new XMLHttpRequest();

  request.open("POST", url, true);

  request.setRequestHeader("Content-Type",

      "application/x-www-form-urlencoded");

  request.onreadystatechange = function() {

    if (request.readyState == 4 && request.status == 200) {

      if (request.responseText) {

        callbackFunction(request.responseText);

      }

    }

  };

  request.send(vars);

}    

This is just the tip of the iceberg. The code above doesn't even take into account formatting the URL or the variables to be sent to the URL; nor does it then explain how to apply the result to the document. It's just the plumbing required to send an HTTP POST request to a URL using AJAX. As you can see, this is not exactly code for the faint of heart.

But if nothing else, JavaScript is a true OO language (perhaps even more OO than Java itself), and it excels at hiding complexity. The Prototype library reduces the code above to this:

new Ajax.Updater(target, url, {method: 'post', parameters: vars});

All of the lines of code in the previous snippet are encapsulated in the single invocation above, which actually even updates the Web page (it inserts the returned HTML into the  DIV in your document whose ID is contained in the variable named target).

The moral of this part of the story is that JavaScript has incredible power and that the frameworks out there make that power available to the everyday programmer (as opposed to the JavaScript gurus who design these frameworks).

Some Frameworks

I wish I could give you a complete rundown of all of the frameworks, but there are just too many. But I can give you a little background on the different types of frameworks and what they offer and then point you to some of the more popular frameworks (as well as a couple of lesser-known but really cool ones I've found during my research).

The Big Four

First, the granddaddy of them all is probably Prototype. As noted above, Prototype is really just an enabling package. It's designed by programmers for programmers to allow you to extend the JavaScript language and easily perform some of the basic functions required to provide a rich user experience. However, Prototype doesn't have any native  support for widgets; that is contracted out to something called Scriptaculous, a library built on top of Prototype. Scriptaculous provides core functions such as visual effects (opacity and movement, for example) as well as basic DHTML features such as creating new nodes or enabling drag-and-drop functionality. Scriptaculous is used extensively within the Ruby on Rails community, but it's also quite popular on its own.

About the same time as Prototype was being designed, another technology called Dojo was making its debut. Dojo is very powerful and has some real power attributes. It has one of the larger development communities, and the growth of its associated libraries (such as Dijit, the Dojo Widget library) has been impressive. Also, like it or hate it, IBM is very much behind Dojo, and thus it's likely that of all the frameworks, Dojo will get the most attention from the Rational developers. Its glaring weakness today is documentation. Where all the other frameworks have extensive documentation, Dojo's is severely lacking, although they are working hard to fix that and the community also has its own "campus" site, dojocampus.org. On the plus side, Dojo a professionally engineered piece of software, with serious attention paid to things like packaging and distribution.

Then there's jQuery. By far the most capable in the area of animations, jQuery allows you to do some fantastic visual effects--things you just don't expect in your browser. Also, jQuery has the best support for XML; it allows you to easily retrieve data from a server in XML format and then parse that for processing into the document. How important this is depends on your focus; when Chris Laffra and I designed the RSDC Scheduler application, we decided to use JavaScript Object Notation (JSON) as our way of communicating data between the layers of the application. I think if your application is a multi-tiered application using primarily internal data, JSON is the way to go, while if you are going to be talking to a lot of outside services, then XML is more appropriate, and that's where jQuery has an advantage. jQuery is also the hands-down leader in documentation, both through example code and online tutorials.

Rounding out the top four you have YUI, the Yahoo UI. YUI is one of those toolkits that comes about organically. As the Yahoo developers needed more and more Web capability, they found themselves creating a common library of functions. As the library became more complete, the developers decided to release it to the public. YUI has a lot of great features and is probably the most well-rounded of the frameworks, but it has a huge negative in that it's perhaps the most intrusive, requiring you to adhere tightly to its HTML conventions (particularly the use of DIV tags to define the attributes). Note that this is not necessarily the worst news; other frameworks--Dojo in particular--use customer attributes that can cause problems for HTML editors. So again, a lot depends on your requirements.

In fact, even if you were to go with one of the top four, which one is best for you depends to a very large degree upon your software development requirements. For example, if WYSIWYG is your thing, pretty much only Dojo and YUI provide that tooling today. The snazziest widgets today are probably in jQuery, along with the best documentation. As befits its somewhat more professional approach to development, Dojo leads the pack in i18n (internationalization) and a11y (accessibility).

Some Others

Quite a few other frameworks exist, although with relatively smaller followings. The big four make up the big percentages, with Prototype pretty comfortably in the lead and the other three jockeying for second place. But other good options do exist.

Some frameworks are built on top of others. Since Prototype doesn't have a robust widgets library, other frameworks provide them, with the primary library being Scriptaculous. However, others are available, and one with some impressive capabilities is Rico. You can see a demo here.

Some toolkits strive for compactness; the folks who created the MooTools library definitely focused their energies toward that goal. MooTools is one of the smallest libraries, yet it supplies a wide variety of elegant features. Another small and powerful library is Mochikit. While perhaps not as full-featured or even polished as other frameworks, it has the benefit of being really, really small.

One of the cooler demos is for Echo3. The transitions and the overall "desktop-like" nature of the user interface are very impressive.

Then there's Ext. Ext is a hugely popular framework, but it's really amorphous, so its use is hard to gauge: The ExtJS version can be used either standalone or on top of Prototype, YUI, or jQuery. Ext can work with Google or ASP.NET. There is some concern regarding the licensing, but supposedly the Ext developers have finally decided on a simple GPLv3 license (I won't spend any time on that here; open-source licensing is a subject best left for long leisurely days and flame-retardant suits).

Some Things That Are Not Frameworks

This is a very important point: Rich UI options exist that are not JavaScript frameworks. Instead, they are rich-client plug-ins that run, with varying degrees of success, inside your browser. The originals were probably Macromedia (now Adobe) Shockwave and Apple QuickTime. Flash was also one of the early pioneers in this arena; in some ways it's a sort of "Shockwave lite."

The difference between these formats and JavaScript frameworks is that you need to create and compile the presentations into a proprietary format using a proprietary tool and then send the entire thing down to the client, which in turn must have already installed the corresponding proprietary player.

The different players have different characteristics. Shockwave, for instance, seems to be pretty friendly and works and plays well with other software, while QuickTime often seems like that horrible weed you just can't get out of your garden no matter how many times you try. And sometimes these players even act as security exposures; QuickTime has had numerous exploits over the years. And really, I'm not picking on QuickTime; other players have issues as well. It's just that QuickTime's bugs are so bad. The last one in November got a U.S.-CERT rating of 10 out of 10.

The latest entry in the player plug-in category is Microsoft's Silverlight. I don't think it's terribly surprising that Microsoft would choose a solution that requires lock-in to both a proprietary format and a proprietary development tool, as opposed to a more open framework style of coding.

Some might argue that a JavaScript framework is similar in that you have to download the framework and then the actual JavaScript for the page, but typically we're talking about much smaller downloads for a framework. More important, though, is the fact that, especially for the open frameworks, what you are sending is raw JavaScript that can be executed on any browser on any machine without having to install any other software. This zero-footprint approach makes it much more likely that anybody on any machine can run your application.

And Then There's Google

I haven't even touched on Google and the Google Web Toolkit (GWT). Google is an odd hybrid in which you use JavaScript to call Google services, which in turn provide rich UI features. For example, Google has APIs that will draw beautiful business graphics for you. All you do is send them the data, and they'll create a line graph or bar chart that you include in your Web page as an image. You can also easily incorporate a map onto a page just by presenting Google with the address.

And really, it's even odder than that, because to use GWT, you write your code in Java, which GWT then translates to JavaScript, which is what you actually send to the browser. It's a rather Rube Goldberg version of the old applet technology, but it has some really powerful capabilities.

My reason for putting Google in the section with the proprietary players is that the Google APIs require that you make a request to the Google servers. Google doesn't charge you anything for this service, and if there's a single Web-based service provider that I'd be willing to trust would always be available, it would be Google. But what if--just what if--Google decided one day to either charge for this service or simply not provide it anymore. That's a business issue that you need to address up front.

Frameworks and EGL

If phrases like "hiding complexity" made you think that a comment or two on EGL would be forthcoming, you would have been correct. One of the foremost goals of EGL is the ability to hide complexity. So the EGL Rich UI tooling and JavaScript frameworks have a natural affinity to one another. That affinity makes EGL very appealing to anybody who wants to get the sizzle of Web 2.0 without having to become an expert on frameworks. That's because EGL will provide wrappers to the more popular frameworks, making it a simple matter of drag and drop to place things on the page.

And don't worry about lock-in, either. EGL is very good about allowing you to create your own EGL/JavaScript interfaces, so if you do decide that you need one of the frameworks that isn't directly supported by EGL, you can easily write your own EGL wrapper classes. But to start with, expect to see good support for both the Dojo framework and the Google widgets.

I'm looking forward to writing more about EGL Rich UI and its use of JavaScript frameworks in coming articles; I think it's the easiest way for an old green-screener like me to be able to get into the exciting new world of Web 2.0. And even if you don't use EGL, you can certainly dip your toes into the JavaScript framework pool by downloading any of the frameworks I've talked about and using them in your own private sandbox. Remember, the majority of these frameworks are strictly client-side and don't even require a Web application server, so you can test them on your desktop in your browser without any special server-side software. So get out there and get dynamic!