This is a brief recap on why we chose Yahoo!'s YUI Library to be our base front-end framework back in 2006; and why we have now decided to migrate away from it.
YUI provided a consistent API to access the DOM, listen for events, make AJAX calls to the server and even animate elements.
YUI made front-end programming something much better than a nightmare. It was even fun. It actually made a lot of nicer UI become feasible in terms of a business decision. For those of you who were not doing web development before 2006, it is hard to overstate just how big of a sea change this was.
jQuery came out not long after, but there seemed little compelling reason to switch.
This was an enticing introduction - and reinforced two of the cornerstones of the library: brevity, and ease of use.
Note that brevity does not always make something easier to use, nor easier to read. Which of the following two hypothetical (and nonsensical) snippets of code is more comprehensible to you:
// this line D("body").$("<"); // or these two lines element = getElement("body"); element.move("left");
jQuery looks a bit like the first line – using symbols and chaining to reach an objective. While YUI looked more like the later – choosing longer, more explanatory method names and multiple statements to reach that same objective.
Somewhat surprisingly, people took to the former in large numbers. Today, jQuery commands over 60% usage in the worlds most popular sites.
My theory is that for some types of development—where one repeatedly does much the same thing in subtly different ways—short cryptic approaches work very well. One's eye gets accostomed to the $ for selecting DOM element and it becomes familiar and even "intuitive" after a while.
I wouldn't be surprised if there are even some novice programmers that don't realize the $ symbol is the jQuery function, and think it is simply "how browsers select elements".
In 2009, the YUI team announced a new major version - YUI 3. This was a total re-write, incorporating some of the lessons learned from using the previous version and from popular libraries such as jQuery. YUI 3 supported chaining and made DOM manipulation simpler. It also supported a dynamic binding system in which pieces of code could be dynamically injected if/when needed rather than all at once on the initial page load.
This dynamic injection was very attractive to us at the time, as our server software was very modular and dynamic in nature. We defined a core group of modules that we always load, and then let each page component load any additionally needed modules.
We continue to use YUI 3 in all our projects (as of January 2015). But we almost certainly won't for the next one.
Also, when distributing for the use in a single browser (Safari), all the additional code contained in the library for browser compatibility is just bloat - and slows things down. In some cases, the slowdown was very perceivable.
We found ourselves writing more of our own modules in place of the YUI versions, partly for performance reasons and partly to take advantage of newer or mobile web technologies. Increasingly, it has become illogical to base our extensions on such a large core - and YUI was not designed to extract useful bits piecemeal.
And of course after their end-of-life announcement (which echoes some of the same concerns I've stated here) – it is clear that the time to migrate away is upon us.
YUI was very well built and helped us reach many of our goals throughout the last 8 years. I am very appreciative of Yahoo! for generously providing this library to the community free of charge, and to the extremely talented developers who planned, implemented and supported YUI.
So what is the better option moving forward?
One obvious choice is to move to jQuery. The community is huge and the plugins are plentiful. There are multiple CDNs which host the "binary" that would speed up delivery and in some cases even eliminate it altogether.
But for many reasons I do not think jQuery is the best choice for us. I'm not saying it is a bad choice for everyone - but I think it would be wise for any developer who is starting a new project to consider the pros and cons of jQuery.
Let me wrap up this article and write up my thoughts on choosing a framework here at beginning of 2015 in a separate post. I will explain in that post why I think jQuery is not ideal in meeting our needs.
I say, what a wonderful problem to have.