In December 2009, editors at Packt Publishing asked me if I’d like to write the second edition of their book on the YUI Library. The original author, Dan Wellman, was engaged in other business at the time, and they needed an author who was broadly familiar with YUI 2. The first thing I thought was: aren’t you a little bit late? Much of YUI 3 was already out in GA and more was coming with every release. But the Packt team wanted to proceed, and I agreed to take on the challenge.

On July 16^th, the new volume came out, YUI 2.8: Learning the Library, not as a second edition but as a new title. In the end, it wasn’t such a bad decision. While the book was going through the editing process, YUI 3 gained the ability to load YUI 2 components from the use() statement. This extends the usefulness of the extensive YUI 2 catalog while taking the pressure off developers to produce YUI 3 versions of all YUI 2 components.

• Sample Chapter: Packt has released a sample chapter from the new volume, covering YUI 2.8 Rich Text Editor, on their website, giving you a flavor of what the new book contains.

The goal with this new volume was to cover all non-beta YUI 2 components. This broad vision forced me to take a deeper look at components I had barely used in their most basic forms as well as others I’d not used at all. However, in contrast to the first edition, a project that began not long after the library had been made public, I had a few years of cumulative experience with YUI ? my own experience paired with that of the many users who share their experiences and advice on the forums and the blog. I was also spared from many blunders by an excellent team of reviewers, two of whom, Caridy Patiño and Iliyan Peichev, are also well known YUI contributors.

To keep the book to a manageable length, I eliminated some images, long examples, and reference material that could be found at the YUI website. While the first edition had at most two components per chapter, the new one has up to four and has a couple of new chapters. Even so, some components didn’t make the cut.

The Evolution of YUI 2

I learned a lot about the YUI Library while writing this book, and the changes I made to Dan’s text were instructive about the library’s evolution since its release in 2006.

The programming style for example code has changed in these years. Instead of creating a namespace (or using YAHOO.example, which is always available as a placeholder), we now tend to fit everything within an anonymous function created when the DOM becomes available. (This style is closer to what we see in YUI 3.) We now use namespaces when we absolutely need to create globally accessible variables (including objects) such as when we create a custom library component. Sandboxing saves us some typing, since we can define functionally-scoped aliases for the objects we use more often from YUI (Dom, Event, Lang are common shortcuts) or variables of our own. This approach also lets YUI Compressor do a far better job.

Having a panoramic view of the whole of the library allowed me to notice how it developed over time. The architecture of the components changed and it is clear how everything has converged into what is now YUI 3.

Early components, like TreeView, had few dependencies. As certain patterns started to become obvious, some basic component infrastructure started to develop. The Container family had a Config object which allowed for getter and setter methods, and so have all the components that inherit from it. It also uses the Custom Event object, which is one of the two ways to work with custom events we have available in YUI 2.

With the release of TabView came the YUI 2 Element Utility, which provided improved getters and setters (via AttributeProvider) as well as better custom events (via EventProvider). Seventeen other YUI 2 components inherit from Element. Looking at the evolution the library, it’s easy to see how the ideas behind Element, as a DOM element wrapper, came to inform YUI 3’s Node. Element’s role as a basis for other components was broken out in YUI 3’s Base and Widget, though the new components are all far more powerful and complete, each in its own area. For example, Node’s all and one methods return Node instances while Element’s getXxxx methods return plain DOM element references, not completely abstracting the DOM.

The two models, Config and CustomEvents on the one hand and AttributeProvider and EventProvider on the other are not totally incompatible. In Menu and Split Buttons both models coexist, as Button inherits from Element and it hosts a regular Menu that inherits from Container.

Undoubtedly, YUI 3 benefited from all of this experience; but YUI 2 also benefitted from YUI3. Cool stuff came from YUI 3 to enrich YUI 2, such as event-delegate and element-delegate and other new events we can listen to (focusin and focusout, mouseenter and mouseleave). This also became possible because of the way we load components, which changed during YUI 2’s lifespan ? most importantly with the introduction of the YUI 2 Loader ? and became formalized as intrinsic support for client-side loading in YUI 3.

Loading affected how the components got designed and how the final component files are built. In YUI 2, to minimize the number of outstanding server requests, the components had to have as much of what they needed packed together. Thus, some components got loosely related objects in them just to have them handy when and if needed, others got a bunch of objects with a whole range of features packed in one file because loading the separate parts was too costly. Then came aggregates such as yahoo-dom-events.js or reset-fonts-grids.css since they are almost invariably used together or utilities.js which gathers all the often used components in the YAHOO.util branch. But the real change came with combo-handled requests, which allowed us to pull any number of script and css files each in just one http request. That makes it less necessary to optimize the packaging of the objects in the library into component files and those into aggregates based on a hypothetical ‘average user’.

In YUI 3 we no longer need to load the ‘container family’ all at once. We can load the separate widget-xxxx files on top of the basic widget according to the features we need. That approach is the standard in YUI 3, but it came as one of the steps in the evolution of YUI 2. Hence, more recent YUI 2 components like event-delegate and element-delegate are packaged separately from from their base components and so is Event’s mouseenter and mouseleave. We might see further splits in library components in future releases, allowing you to choose more specifically the feature set you want and leave unneeded code off the page.

This is a story of progress, a process that necessarily went though some failed efforts. Why doesn’t TreeView inherit from Element or why hasn’t Container, and thus Menu, switched to Element or, at least, to AttributeProvider and EventProvider? Technically, the answer is ‘backward compatibility’, but in more general terms it is ‘respect’. There are thousands of websites (and tens of thousands of developers) using the the published public interface of the YUI 2 components. Making those changes would break many applications or would cut them off the upgrade path, should they want to benefit from a code fix or a new feature. Being so respectful of the installed code base is a library feature in itself. Being respectful to us, who create that code, is a feature of the people in the YUI team, and I’m very grateful it is so.