YUI 3.0 Preview Release 1

By YUI TeamAugust 13th, 2008

YUI 3.0 Preview 1 website.The YUI team is pleased to announce the public availability of YUI 3.0 Preview Release 1, an early look at what we’re working on for the next generation of the YUI Library. Documentation for YUI 3.0 is on the YUI website; the download is available on the YUI project area on SourceForge; you can find us with questions or comments on the YUI 3.x discussion forum. Keep in mind that this is an early preview, not a production-quality (or even a beta) release. This release is not suitable for production use, but it will give you an idea of what we’re working on, and it should provide a good framework for conversation about the future of the library.

Five Goals for YUI 3:

We’ve talked to thousands of YUI users over the past 30 months, and based on that feedback we’ve set five design goals for the next generation of the library. What you’ve told us is that YUI 3.0 should be:

  • lighter (less K-weight on the wire and on the page for most uses)
  • faster (fewer http requests, less code to write and compile, more efficient code)
  • more consistent (common naming, event signatures, and widget APIs throughout the library)
  • more powerful (do more with less implementation code)
  • more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

With this early release, we’ve made progress toward most of these objectives — and we believe we have the right architecture in place to meet all five as we move to GA over the next few quarters.

What’s New in YUI 3.0?

When you start to write code using YUI 3.0, you’ll notice some changes in structure and style. Here’s a taste:

Snippet: What it does:
YUI().use('node', function(Y) {
Creates a YUI instance with the node module (and any dependencies) and adds the class "enabled" to the element with the id of "demo".
YUI().use('dd-drag', function(Y) {
        var dd = new Y.DD.Drag({
        node: '#demo'
Creates an instance of YUI with basic drag functionality (a subset of the dd module), and makes the element with the id of "demo" draggable.
Adds the class "enabled" to the all elements with the className "demo".
Y.all('.demo').set('title', 'Ready!').removeClass('disabled');
Sets the title attribute of all elements with the className "demo" and removes the class "disabled" from each.
Y.get('#demo').plug(Y.Plugin.Drag, {
    handles: 'h2'
Adds the Drag plugin to the element with the id "demo", and enables all of its h2 children drag as handles.
Y.on('click', function(e) {
    e.target.query('em').set('innerHTML', 'clicked');
}, '#demo a');
Attaches a DOM event listener to all anchor elements that are children of the element with the id "demo". The event handler prevents the anchor from navigating and then sets a value for the innerHTML of the first em element of the clicked anchor.

What’s different here?

  • Sandboxing: Each YUI instance on the page can be self-contained, protected and limited (YUI().use()). This segregates it from other YUI instances, tailors the functionality to your specific needs, and lets different versions of YUI play nicely together.
  • Modularity: YUI 3 is architected to use smaller modular pieces, giving you fine-grained control over what functionality you put on the page. If you simply want to make something draggable, you can include the dd-drag submodule, which is a small subset of the Drag & Drop Utility.
  • Self-completing: As long as the basic YUI seed file is in place, you can make use of any functionality in the library. Tell YUI what modules you want to use, tie that to your implementation code, and YUI will bring in all necessary dependencies in a single HTTP request before executing your code.
  • Selectors: Elements are targeted using intuitive CSS selector idioms, making it easy to grab an element or a group of elements whenever you’re performing an operation.
  • Custom Events++: Custom Events are even more powerful in YUI 3.0, with support for bubbling, stopping propagation, assigning/preventing default behaviors, and more. In fact, the Custom Event engine provides a common interface for DOM and API events in YUI 3.0, creating a consistent idiom for all kinds of event-driven work.
  • Nodes and NodeLists: Element references in YUI 3.0 are mediated by Node and NodeList facades. Not only does this make implementation code more expressive (Y.Node.get("#main ul li").addClass("foo");), it makes it easier to normalize differences in browser behavior (Y.Node.get("#promo").setStyle("opacity", .5);).
  • Chaining: We’ve paid attention throughout the new architecture to the return values of methods and constructors, allowing for a more compressed chaining syntax in implementation code.

And that’s just the beginning. Dive into the examples to learn more and to see the preview release in action, including some hidden gems like full A-Grade cross-domain requests. Our resident metahacker Dav Glass created a nice multi-component example, the draggable portal, that will give you some sense of what’s included in today’s preview.

Is YUI 3.0 Backward Compatible with YUI 2.x?

No. YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

We know that ease-of-migration will be a critical factor for all YUI users. We’re taking two important steps to facilitate the transition as it arrives:

  • Limited compatibility layer: YUI 3.0 will ship with a limited compatibility layer for the current YUI Core (Yahoo Global Object, Dom Collection, and Event Utility). This will allow you to run many of your YUI 2.x-based implementations on top of YUI 3.0. We’re not shipping the compatibility layer with today’s preview, but you’ll see it appear in a future preview or beta release prior to GA.
  • Full parallel compatibility: YUI 3.0 can be run in parallel to YUI 2.x with no side effects for either version. If you choose to make the transition in stages, you can run the full 2.x stack and 3.x stack together as needed.

Even with these provisions in place, we know that an API change (along with new concepts and idioms) has a real cost for everyone involved. We’re convinced that this change is both necessary and worth the effort, and obviously we’re going to work hard to make the value proposition compelling.

What’s Next?

YUI 3.0 is a work in progress. The common widget framework for 3.0 is not included in this preview and we’re continuing to work on refinements to the core — including optimizations to the package structure to minimize base K-weight. We anticipate the next two releases coming up as follows:

  • October 2008 — PR2: Widget Framework, sample widgets, additional utilities.
  • December 2008 — Beta 1: Final mix of module structures, API completion, full complement of utilities.

We have some great stuff to share as we move further along in this process. We’ve never been more excited about YUI and its future — and we think YUI 3.0 will have a big role to play in that future.


  1. awesome! looking forward to 3.x. already happy with 2.x

  2. You guys rock!

    I really think that the new syntax worth the effort.

    I’m really excited about the Custom Event++ implementation (that’s my specialty).

    Also I think we should clarify that the main change between YUI 2.x and YUI 3.x is the way that we get DOM references, in 2.x we just get DOM elements, but in 3.x we get YUI Node instances. This feature will allow us to create execution chains. For example:

    2.x -> YAHOO.util.DOM.setStyle (YAHOO.util.DOM.get(‘demo’), ‘color’, ‘#fff’);
    3.x -> Y.get(‘#demo’).setStyle(‘color’, ‘#fff’);

    Anyway, this is the begining of the end…

  3. Bravo. The new syntax seems super easy to follow.

  4. Congratulations. YUI has been a core part of our work. We are looking forward to v3.

  5. steve krutzler said:
    August 13, 2008 at 11:35 pm

    now we just need a converter that migrates 2.x code to 3.x!! haha.

    love the lightweight nature of 3.x. definitely some perf improvements will be gained when a site full migrates.

  6. Good stuff. Chaining and selectors are great, and file loading replaced by .use is even better.

  7. why not setStyle({opacity:.5}) ?
    it could be used to set more than one property at a time, and doesn’t use string, which looks clunky.

  8. great work guys ! Nevertheless, I’m not sure the YUI modularity concept is such a good things. Yes, it will allow user to download less JS nut on the other hand, we will have much more HTTP requests than we have today.
    Currently, on Kelkoo, we use a single minified, abfuscated and combined JS file on each page. With YUI 3.x, will we be able to keep this or will we have to include (statically or dynamically) more files ?

    Other concern : with YUI 3.x, we will use Selectors instead of “classical” getElementById and getElementsbyClassName. This is great since it will allow us to be more flexible and to reduce number of source code but I’m afraid that parsing the DOM to search for a given selector would be less performing than a simple getElementById. Actually, we have a 32K lines Javascript file on our site with lots of getElementsByClassName and there are a real pain in the ass in term of performance ! With Selectors, I’m afraid that performance will be badder as it currently is.

    Another point : chaining. In many developing langage, chaining is seen as a very bad coding method. Why should it be different in javascript ? If only one of the call returns “null” or “undefined”, we will get an Exception. Can you ensure us that, even if there is no elements with id “demo”, a call to “Y.get(’#demo’)” will not return this kind of value ?

    But, many congratulations for this release ! Can’t wait to use it even if I know that we won’t be able to use it on production before a few months !

  9. Matt Sweeney said:
    August 14, 2008 at 1:28 am

    Hi kl,

    You can use the setStyles method to pass an object literal:

    myNode.setStyles({opacity:0.5, background:'yellow'});

  10. Brilliant – this marks serious progress for what was already a brilliant javascript library!

  11. great work guys. look forward to migrating. Keep up all the hard work, it’s very much appreciated

  12. I got to tell you, one of the reasons I use YUI versus Prototype or jQuery is that while verbose, the syntax was very very readable in YUI. I feel the new syntax takes away from that readability. I know developers don’t like to type, but the YAHOO.namespace.object approach I felt was a mature way to use JS, and I fear it may be on the wayside based on the examples above.

    I’m a visual studio user, and Visual Stduio 2008’s code hinting got me around all the typing, while maintaining code readability.
    YUI and Visual Studio Code Hinting

  13. Cool, YUI will rule all over ! ;-)

  14. You really rock! YUI is incredible.

  15. @Ed G.

    Just because YUI 3 supports chaining, doesn’t mean you have to use it. That support is there if you want to use it.

    You can still code like this:

    var el = Y.get('#foo');

    Also, Y.namespace is still available and used. Drag & Drop is namespaced under DD.
    Which in YUI 2.x, would be the equivalent of:

    var el = new YAHOO.util.Element('foo');

  16. @Rémi

    Personally I like using selectors because they allow for more flexibility. The YUI Selector engine is pretty smart, there should me no performance hit from this:

    to this:

    And as I said in my last comment, chaining isn’t a requirement, it’s a feature ;)

    If you are worried about null values, you can still do something like this:

    var el = Y.get('#foo');
    if (el) {
    el.addClass('selected').setStyle('color', 'red');
    el.set('innerHTML', 'This worked..');

  17. Kick ass. This is excellent guys. I’ll scour the docs throughout the week and have a play. It looks pretty exciting.

  18. This looks great! More jQuery-like syntax will be welcomed by me with open arms.

  19. All great, but chaining is not.

    I’m not sure if chaining as an option would be that bad, but looking at snippets you seem to focus peoples attention on this functionality.

    Those code samples doesn’t look nice. It will be probably significantly harder to enforce good coding practices in our companies.

    But if this will help to widespread this very best library then maybe it is worth…

    Maybe it’s worth too look at BDD instead of TDD as a more modern alternative.

  20. I hope that the new YUI syntax is not a result of caving to all the jQuery fanboys out there. I’ve been using a number of the YUI 2.x libraries in our app and have appreciated the somewhat robust nature of the code that must be written for it. jQuery, in my experience, has always led to poor code quality and difficult maintainability over the life of an application. I’m sure this is at least partially the fault of the developers writing the code, but I’ve always like that with YUI, to make it work you have to write pretty legible code.

    Anyways, enough of my “angry-about-change” rant, what’s the plan (if any) for future development of the YUI 2.x library?

  21. @Greg,

    See Dav’s note above regarding chaining — that really is a choice you get in 3.x, not something that is enforced.

    With respect to YUI 2.x, we have the 2.6.0 release coming up (planned for next month) with big work on DataTable, Menu, RTE, and more, and with a new Carousel Control. We will soon publish preliminary plans for 2.7, including increasing community contributions; community members are right now working on enhancements to TreeView, a forms component, and more, and we are working to make it easier for folks to contribute new work to the library. The core of YUI 2.x should remain stable and has in fact changed little since 2.3.0, but the 2.x codeline is still our principal offering, and it will be for a long time to come.

    Check out the Roadmap for the official “next steps” that we’re working on for YUI.


  22. Dave Schoonover said:
    August 14, 2008 at 9:13 am

    Nice work!

    I’ve always been fond of the functional style; it’s one of the great design decisions of jQuery, imo, and a very natural fit for most DOM-related coding.

    Great to see YUI on board!

  23. Great stuff guys. I can’t wait to try it out.

  24. Please, don’t address our doubts saying that this is not an issue because it’s mere optional. It’s a significant shift in philosophy of this library.
    Write another blog post maybe or something… :)

  25. It’s excellent to see this! I like the less verbose format, (ie, jQuery). I use YUI in a limited fashion, because of the size, and because of the verbosity of the code – sometimes seems unnecessary to me. But great to hear there! Looking forward to getting to spend some time with it

  26. Matt Sweeney said:
    August 14, 2008 at 3:16 pm

    @Kamil T.

    We’d love to hear more about your concerns regarding some of the changes we’ve made.

    If you haven’t already, please join our yui3 group:

  27. Fantastic work, guys! I have to say selector-based targeting and chaining have been the top two things on my wishlist for a while, and it’s great to see them implemented here.

    Even better: the decisions you’re making are well-informed, and only help to improve an already-sound architecture. I can definitely see the performance wins that 3.0 will realize across the board.

    You’re slowly but surely eliminating any reason preventing my jQuery buddies from seeing the light. ;-)

  28. well done guys, yui3 is looking good.

    Shame I just got my head round yui2, that learning curve just keeps getting higher. Hopefully not quite so much this time!

    Thanks for the great effort, yui has been a lifesaver on many occasions.

  29. I have been working with YUI 3 for quite a while now and I’m not sure whether I like the changes yet. The JQuery-esque new syntax is IMHO unnecessary. If people want selectors there’s already a perfectly good selector component in 2.x.

    What I always liked so much about YUI is the fact that you actually have to write JAVASCRIPT to use it. It never imposed some weird alien syntax that first needed to be learned before being able to use it like it’s the case with many other libraries.

    The biggest ‘mindfuck’ is switching between 2.x and 3.0 when you have to alter use of YAHOO.util.Dom.get(‘foo’) with Element.get(‘#foo’); and other similar substantial changes. YUI 2.x is made like an uber powerful set of helpers while YUI 3 seems to want to change the way we program Javascript.

    I don’t know if this makes any sense but I have some problems with calling this a 3.x version of the same library that’s currently at 2.5.2. It feels like it’s a totally DIFFERENT library and not a newer and more powerful version of a library that I already love.

    I can definitely see some advantages in the new approach but I’m not sure yet whether I feel the love. Different? Definitely. Better? I’m not sure.

    I suppose both approaches deserve to exist and I’m definitely not sure whether I like to see this new approach replace the 2.x one, even if this only happens in the fairly distant future.

    Just my 5 cents!

  30. Looks amazing, guys!

    I am happy to see that you took the leap and made YUI 3.x incompatible with the old stuff. While I am sure I’ll swear at you a bit while I convert stuff over, the benefits of the new interface and streamlining will definitely be worth it.

    Looking forward to it!


  31. And how about XHTML? This language requires some special handling in some cases (due to namespaces, inability to use document.write and few others). Short question is: can I even try to use YUI PR1 on such web sites?

  32. Great work from the team, but is this new version a good news ?

    I’m not sure I will use it. Like Marco what I want is writing JavaScript. I don’t want to learn one more syntax and one more specific usage of JavaScript. I have not the time for this. The learning curve is not so small when you want to implement things that are not only copy/paste from the examples and the docs.

    Why this fucking syntax àla JQuery. Yes it’s not verbose but it’s not so easy to read and to understand when you are in maintenance phase. If I want a JQuery chaining, I will use JQuery (wich has a ton of addons), but if I have choosen YUI it’s precisely because it’s not JQuery.

    I use YUI since 18 months for a huge application. With the differents releases of version 2, I sometime have to remove and replace some composants (menu, editor) because the personalisation ask to much work (changes in the CSS for example) or because the usage was not too easy and sometimes eratic (editor).
    Now the team say clearly that version 3 and 2 will not be compatible. I am very disappointed because for me it’s like all this months of work could be put in trash. All must be rewrite and retested if I want to always be in the race (:-(((

  33. I just wanted to say that I found it hard to figure out how to install and use the YUI library – the current YUI site (http://developer.yahoo.com/yui/) has so much going on that I just could not find a simple method to install and use the library. I’m not really a noob either.

    This was after using YUI on another project which already had it installed – in this instance it was easy to use the API to figure out what I needed to do. But installing from scratch was too difficult and I used jQuery instead.

    I hope you have a basic installation example for other not-so-noobish, even a way to isntall the whole library at once to play around with it to accompany the super light install procedure.

    Cheers though! Thats my only gripe.

  34. I already love 2.0 but now in 3.0 what it looks like to me is we are basically becoming dojo. The dojo people already enforce their own package management system on the user. My package management system of choice is JSAN:

    If you look at the dojo code it looks a lot like the YUI code, in that it looks like it has already went through an obfuscator.

    I am sorry but I don’t know if I am going to use this library anymore I have no reason to like YUI 3.0 then I do to like dojo or jQuery. My greatest objection is that YAHOO.util.YUILoader is enforced on the user.

  35. You can forget what I said before. YUI 3.0 looks like the most awesome JavaScript library ever developed. Its not obfuscated, it is elegant, and it is almost as easy to write as Perl =/