2007 / July 7^th/ A few days with YUI

On a recent project I’ve been working with, the client wanted YUI, so we gave them YUI. Overall, I’ve been extremely disappointed with the framework. Here are my initial impressions, for what it’s worth. (Similar impressions of MooTools)

Is it the DOM or the Dom?

It’s bad enough that Yahoo! namespaces the crap out of everything, but what makes it worse is the inconsistency in which they do so. Let’s say you want to add a class name to element. No problem: YAHOO.util.Dom.addClass(element, 'class-name-here'); Alright, so now you’d like to add func to the DOMReady handler. So now it’s YAHOO.util.Event.onDOMReady(func);.

These kinds of omissions show to me that Yahoo doesn’t believe in syntactic sugar (one of my primary judging points for any framework). Don’t take me for stupid, I fully understand why they did this (as all modules are word-cased, such as Event, Panel, etc). This makes a lot of sense when writing documentation, but little to no sense when writing code.

Not quite browser compatible

I was actually very surprised by this. It seems like YUI is still not quite mature. I had some pretty harsh issues with the Drag and Drop library, Safari, and certain CSS styles on parent containers. Granted this is no easy task: but it was one I had hoped the YUI team had tackled. So far I’ve worked with the drag and drop libraries from MooTools, Script.aculo.us, and now YUI. YUI’s implementation (aside from namespacing) seemed best to me with the exception of Safari. Ultimately, the widget I was building needed to be hidden from Safari because we didn’t want to start hacking core JS files.

I fully understand the frustration with Safari (and no doubt, it is most likely fixed in Safari 3). But, to me Safari is a target platform, so I’ll choose a framework that keeps this in mind. Also keep in mind there are many bugs with relatively-absolutely positioned draggers (things you drag inside an already positioned box), especially if that box moves after the page has loaded. This may seem like an outlier-case, but it happens all the time in real-world implementation.

Anti-chaining

While it seems like the majority of popular frameworks out there are putting a huge effort into chaining, YUI is extremely anti-chaining. The end result is that working with the DOM becomes a huge pain. Doing things like adding classes and moving elements around becomes extremely cumbersome without writing your own library to run on top of YUI.

Let’s say you want to add a class to each element with the class name of “star-rating” when a#star-activator is clicked.

MooTools

$('star-activator').onclick = function(){
        $$('.star-rating').each(function(el){
            $(el).addClass('active');
        });
    }

YUI

var activator = YAHOO.util.Dom.get('star-activator').onclick = function(){
  var raters = YAHOO.util.Dom.getElementsByClassName('star-rating');
  for (var i=0; i<raters.length; i++){
    YAHOO.util.Dom.addClass(raters[i], 'active');
    }
}

Now, it’s not so much the number of lines that makes the big difference to me: it’s the elegance of the underlying code. To me, $(el).methodName(value) is so much more semantic than NAMESPACE.package.Module.methodName(el, value)

Yahoo’s Hosting of YUI

I wasn’t aware of this, but Yahoo now offers free hosting of YUI with versioned, optimized files that you can grab straight from their servers. This is a great move, and one I wish more javascript frameworks would employ. If you think about it: if the majority of the frameworks were served from one location, the cost of Javascript frameworks (bandwidth-wise) would be almost nil.

There is of course the issue of requiring Yahoo!’s servers can keep up with your demand. Also, you’re banking on the fact that no one hacks into their servers and replaces the javascripts with some nasty malicious code. For me, I’m a trusting person, but other’s might not think the same way.

Conclusion

It’s not that YUI is a bad, feature-incomplete, or undocumented library: it’s just a very ugly one to me. There’s a lot of functionality baked into YUI, but getting to and understanding that functionality is not for the faint of heart. The API is difficult to use, and the differentiation between API, Documentation, and Examples is extremely confusing to newcomers like myself.

It feels a whole lot like a forced framework as DHH would say. Other frameworks like Prototype and MooTools have evolved out of a need of functionality. YUI feels a lot like someone gave developers a certain task like: “Create a Drag and Drop library with x, y, and z requirements.” The difference is that the code is built for examples, not real-world usage. The overall architecture and planning is superb on paper, but much of that effort is lost for the real-world developers.

For me, my framework of choice is still going to be MooTools. Over the past two years of working with Javascript heavily, I’ve yet to run into a namespace conflict: and I think YUI amplifies this myth that namespaces collide all over the place. I’m too much in love with my sugary syntax, native extensions, and wonderful documentation.

1. 

   Matthew Pennell

   July 10^th | #

   jQuery also (kind of) do free hosting of their source code via Amazon’s S3 - aside from the DDOS attack that took out their DNS and screwed those links a few months back, it’s another plus point for what would be my library of choice.

2. 

   Rick

   July 10^th | #

   MooTools
   $(’star-activator’).onclick = function () { $$(’.star-rating’).addClass(’active’); };

   Even shorter!

3. 

   Phil Freo

   July 10^th | #

   I would agree with you on many points, but the long namespace is much helped when you do things such as:

   YUD = YAHOO.util.Dom;
   YUE = YAHOO.util.Event;
   function $(el) { return YUD.get(el); }

   It’s annoying to have to do this at the top of your JS files, but assuming your code is wrapped in an anonymous function, you get shorter code and a contained namespace. I do miss chain-ability and being about to do “div#myID.myclass”. Check out http://dedchain.dustindiaz.com/ for this.

4. 

   Mike Potter

   July 10^th | #

   Have you checked out Adobe Flex? It removes the browser compatibility problems by relying on the Flash Player to display the UI.

   http://www.flex.org/

   Mike
   (I work for Adobe)

5. 

   Kyle

   July 10^th | #

   Mike: If you’ve followed my blog, you’d see that I have indeed checked out Flex. However, it’s not really an issue when describing Javascript frameworks. The “browser compatibility” issues are null and void if you use most frameworks (I’ve not had an issue with MooTools, Prototype, etc).

   I know Adobe/Macromedia loves touting the “end” of browser compatibility problems, but really we’re just trading browser compatibility with Flash Player compatibility at the end of the day :)

6. 

   zhaozexin

   July 16^th | #

   you can do it like this:

   YAHOO.util.Dom.get(’star-activator’).onclick = function(){
   var raters = YAHOO.util.Dom.getElementsByClassName(’star-rating’);
   YAHOO.util.Dom.addClass(raters, ‘active’);
   }

   YUI and prototype are two flavor!

7. 

   Andy Kant

   July 19^th | #

   We’re using YUI on a project at work. The namespacing is kind of a pain, but you can always alias the namespaces like Phil said. The only reason we’re using YUI over Mootools or Prototype is the quality of the documentation (which can go a long way in the usefulness of a framework).

8. 

   Noel da Costa

   October 22^nd | #

   I’m likeing Mootools visually and syntactically, but it’s missing one killer feature that YUI provides… namely the DataTable. Does anyone know:

   a. whether there’s a DataTable with sorting and pagination for MooTools (or whether this would even be feasible with Mootools framework)

   b. whether it would be possible to use MooTools in general for GUI stuff, but then switch to YUI for handling data tables?

   Ta.

9. 

   Walter Rumsby

   December 20 | #

   You could actually rewrite the YUI example as:

   YAHOO.util.Event.addListener(’star-activator’, ‘click’,
   function() {
   YAHOO.util.Dom.getElementsByClassName(’star-rating’,
   function(el) {
   YAHOO.util.Dom.addClass(el, ‘active’)
   }
   );
   }
   );

10. 

    jminkler

    March 28^th | #

    YUI is not meant to be a replacement for jquery, or even a js framework, its for UI widgets.

Name

Email (will not be published)

Website (optional)