Yahoo! UI Dominates Javascript Frameworks
December 14th, 2007I just recently finished working on a little UI component for a client. Due to the requirements of the component, I knew that a Javascript framework was going to be the only way to go. After some initial poking around and playing with some of the major frameworks out there, I decided that the Yahoo! UI framework best fit my needs as a developer.
I know the Javascript framework debates are nearly as hot as the Web Application framework debates, so I thought I might as well throw my two-cents into the fray. Why is it that as geeks we all love technology so much, and yet we always segment ourselves into factions based on unanswerable debates over what technologies are best: Linux vs. MS vs. Apple, PHP vs Asp.Net vs Rails, Dojo vs Prototype vs YUI? Oh Well, I guess that is an issue for further debate.
Anyway, on to the heart of the matter. My ultimate decision came down to choosing between the YUI, Prototype/Script.aculo.us and Dojo. Some of the major features I was interested in were Dom abstractions, good documentation/examples, animations, and support for namespaces.
I’ll start with the two that I didn’t like and explain what I like and don’t like about them. I was only able to play with these for a brief time so please don’t shoot me for missing or ignoring aspects of these libraries.
Dojo: Dojo is an extremely mature javascript framework. It handles all of the things one would hope for out of a framework including Widgets, Animations, Dom interactions. One of the great things about the Dojo library is it has a huge repository of developer built and maintained extensions to the main Dojo toolkit.
Dojo takes an interesting approach to Javascript development. It turns it into Java-like development. All of the Dojo libraries, widgets and extension are stored in ‘module’ files. Each module is responsible for loading any other modules that it is dependent upon. This is a great model for server development as it allows the developer to be ignorant of the dependencies of the libraries that he is using. However, I think it is a horrible model for a web-based client framework where file size and bandwidth are so vitally important to application response time and usability.
If I include a module on one of my pages that goes out and includes 20 other modules, all of a sudden the amount of javascript that has to be transferred with my application grows by 20 times most likely without my knowledge.
I can appreciate this approach, as there are more experienced Java programmers than Javascript programmers, and it makes javascript development much more modularized, but I just don’t think that it is the right approach for a system that is so dependent on what/how much gets sent to the client on each page.
Script.aculo.us/Prototype: Technically, these are two separate libraries, but in all fairness to them you must consider both of them together when comparing them to YUI or Dojo. Prototype is the base library that contains all of the good Dom interaction, javascript language extensions, and event models. Scriptaculous is a widget animation library built on top of Prototype.
Prototype is a very well built library from what I can tell. It is really worth a look if you are looking for a compact javascript language extension library. It is built into Rails and therefor benefits from the entire Rails community for support. I very much enjoyed prototype and I think I will use it for any projects in the future that do not need any widgets or animations. It also has very good documentation, if you’re into that kind of thing.
Scriptaculous is a library of animations, additional Dom utilities, Ajax and Drag and Drop. It seems to handle these tasks well. There are some good examples on their website showing some of it’s capabilities. It is also built into the Rails framework so it also benefits from the Rails community. The biggest drawback I found with this library is it’s lack of good documentation. I found it hard to figure out how to use some of the different aspects of the library. The other major drawback to this library is it’s lack of namespace. All of the objects are declared in the global namespace. I believe this to be really bad practice. Here at my company we have recently had an issue on a large project where two different client side libraries overlapped and were using the same variable for different things. This is very bad and quite difficult to fix.
Yahoo! User Interface Library (YUI): I am really quite impressed with the YUI library. It is very extensive and contains libraries that handle everything from Dom extension, event interaction, animations, to a host of pre-built widgets. The documentation is pretty good and there are lots of examples for every different library showing how to use them for the most common tasks.
All of the major components of the library are split up into different files. As a developer you are responsible for including all dependencies of each library. Most of the pure javascript extension libraries aren’t dependent upon anything but the general Yahoo! global library. A lot of the widgets and more complex Dom dependent libraries are dependent upon 3 or 4 different libraries and this can definately increase the amount of javascript that has to be sent to the browser, but at least I am responsible for including those files and I am responsible for deciding if 5 javascript includes is acceptable on a page (unlike Dojo).
All of the libraries are namespaced under ‘YAHOO’. This is a great feature that guarantees to me that this library won’t step on the feet of any other included client side code I may be using in my application. However, it can make for some long function calls as everything tends to be 'YAHOO.util.Event.addListener'. This can become tedious when writing a lot of javascript based on these libraries, but it is a tedium I am more than happy to accept.
There are a number of examples for each library along with a user’s guide and a short ‘Cheat Sheet’ for each of the library components. This makes development of common tasks really easy as they show you exactly what needs to be done. For anything more complicated or outside of the realm of the norm, there are two resources that I have found very helpful: the full API for each library and the un-minified versions of the build files for the libraries. The api covers all of the events, functions, parameters, etc for everything in each of the libraries. It is an invaluable resource for delving into the intricacies of the libraries. Finally, for those willing to brave the actual code the un-minified versions of the library files provide the exact inner workings of the libraries allowing you to determine exactly what happens when you call a function allowing you to accomplish exactly what you need.
The final item that I find a nice cherry on top is that Yahoo! willingly allows you to serve the javascript library and supporting css files from their servers. This means that you don’t have to worry about maintaining the appropriate versions of all the files on your development, testing, and production servers. It also means that your users benefit from Yahoo!’s extensive server network meaning that your Japanese user’s will pull the YUI files from the Japanese Yahoo! servers instead of your US based servers.
I’m sure your mileage will vary, but for the project I just finished and any future UI dependent, widget based javascript development I do, I will use the Yahoo! UI libraries. They are well built, well documented and take care of most of the heavy lifting of supporting multiple browsers meaning I get to focus on what I do best, solve problems.
