The End of YUI: A New Dawn of Front End Development

Why We Chose YUI

Prior to the release of YUI back in 2006, our use of front-end javascript was mostly relegated to simple form enhancement tasks and little visual flourishes. There were plenty of stumbling blocks at each turn as we navigated vastly different DOM management APIs, which was a whole lot of un-fun.

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. 

YUI wasn't the only javascript framework around - Prototype and Script.aculo.us had been out for about a year by the time YUI was released; and they were (and still are) very capable libraries. But YUI had the force of Yahoo! behind them, and a team dedicated (and paid) to ensuring compatibility across a wide set of browsers. This compatibility was identified and graded enabling us to commit to our clients to a very specific support agreement.

jQuery came out not long after, but there seemed little compelling reason to switch.

The Rise of JQuery and the Value of Brevity

As developers (re)discovered Javascript and front-end programming, they predominantly chose jQuery for their front-end framework. I suspect a big part of "why" so many people chose jQuery over others was their front page had a very clever "sell" - it had you type a line of code which would animate some element on the screen, after which they exclaimed "You just wrote your first jQuery script!"

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".

YUI 3 and Dynamic Script Injection

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. 

The Paint begins to Peel

The first real sign that the YUI 3 approach was less than ideal in many cases was when we started doing mobile development – particularly for app-store distribution.  Since mobile app packages must contain all necessary Javascript, we needed to identify all possible script files – and this turned out to be surprisingly painful. Its do-able, and we have several apps in the store now as a testament, but YUI has no mechanism for identifying or creating that subset. 

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.

The Future So Far

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 will finish by stating that there has never been a better time to be a developer. The volume and quality of open-source has exploded in recent years – particularly for front-end technologies and Javascript. In fact, it has led to some to complain that there is too many available frameworks, with more emerging daily, making it near impossible to choose or be comfortable after you have chosen.

I say, what a wonderful problem to have.