Wednesday, September 30th, 2009

YUI 3 Is Out!

Category: Library, Toolkit, Yahoo!


The YUI team has put out YUI 3.0:

We’re pleased to announce today the general-availability release of YUI 3.0.0. YUI 3’s core infrastructure (YUI, Node and Event) and its utility suite (including Animation, IO, Drag & Drop and more) are all considered production-ready with today’s release.

This is a ground-up redesign of YUI:

  1. Selector-driven: YUI 3 is built around one of the lightest, fastest selector engines available, bringing the expressive power of the CSS selector specification into actions that target DOM nodes.
  2. Syntactically terse: Without polluting the global namespace, YUI 3 supports a more terse coding style in which more can be accomplished with less code.
  3. Self-completing: YUI 3’s light (6.2KB gzipped) seed file can serve as the starting point for any implementation. As long as this seed file is present on the page, you can load any module in the library on the fly. And all modules brought into the page via the built-in loader are done so via combo-handled, non-blocking HTTP requests. This makes loading the library safe, easy and fast.
  4. Sandboxed: YUI modules are bound to YUI instances when you use() them; this protects you against changes that might happen later in the page’s lifecycle. (In other words, if someone blows away a module you’re using after you’ve created your YUI instance, your code won’t be affected.)

It’s especially nice to see the new terse YUI namespacing, so you can just type YUI() instead of the older longer syntax.

The cool thing about YUI (and this release) is that it is literally driving the Yahoo! Home Page. That’s pretty awesome of Yahoo! to release this code and make it generally available to the wider community. Congrats to the whole YUI team on the new release.

See the original announcement blog post on getting started with YUI 3.0 in 3 easy steps.

Related Content:


Comments feed TrackBack URI

Question is: Did the folks at Yahoo! throw out their own selector-engine and implement Sizzle? And if they did, why are they keeping it a secret? :)

Comment by roosteronacid — September 30, 2009

Just great!

Comment by stoimen — September 30, 2009

I’m a little sad to see that CSS Grids has been dropped from YUI3 – I was really looking forward to an updated implementation of that.

I know they do plan on bringing it back with a fancy new approach, but it’s a shame it couldn’t make it into the GA of YUI3..

Comment by alexleonard — September 30, 2009

@Alexleonard: this is nothing but a finished project. Many modules are still in beta, and (@roosteronacid) Sizzle has some major points over YUIs selector: for instance, you will not want to use dots or colons in ids, the selector can’t handle them (see

Comment by Willywongi — September 30, 2009

Yahoo says:

YUI().use("node", function(Y) {"#message").setContent("Hello, World!");

Javascript says:

document.getElementById('#message').innerHTML = 'Hello, World!';

Comment by jdlfkandslkfajs — September 30, 2009

I really wish they would have used Sizzle. That engine hauls.

However I will reserve judgement if I could see some updates to Slickspeed and Taskspeed using YUI 3.

@Willywongi I know edgecases should be accounted for, buy why a colon in your element id?

Comment by someguynameddylan — September 30, 2009

Wrapping everything you do with functions that load dependancies looks horrible, I get the idea behind it but would’ve liked it if that was taken care of internally.

Comment by Jadet — September 30, 2009

One thing that’s not mentioned in this blurb is that the YUI team sliced most of the modules into very small pieces so the code footprint for importing (say) a single widget is WAY smaller than it is for the YUI2 equivalent. The event system and the flow/control thereof is also much improved so overriding specific behavior is easier.

FWIW, I’ve been poking at it for a few months now and it’s the first library since MochiKit that I’ve been impressed with for client side app building (I only like jquery for adding ajax sprinkles to a server side webapp).

P.S. Last I heard Dojo’s Acme was faster than Sizzle.

Comment by grayrest — September 30, 2009

I would say, that splitting YUI into smaller parts is against the rule to have less http request for a page based on Yahoo’s advice imho.

Comment by CarstepHUN — October 1, 2009

@someguynameddylan I agree about the oddity of using colon in ids, but it’s totally legal (w3c speaking) and I found it useful to build some sort of logical hierarchy in (#tree, #tree::node, #tree::node::leaf) that can’t be achieved through the DOM.

Comment by Willywongi — October 1, 2009

From what I understand, YUI takes care of figuring out which modules to request based on what you declare you need, and then it still transfers them in a single HTTP response. The point is, if you need less, you get less. But if you are declaring dependencies for most of the YUI suite, you’ll get all of them (probably/hopefully) all at once, which will be similar to YUI2 experience. But if you need less, things should be snappier.

Comment by shadedecho — October 1, 2009

that means, I need to use some server side technology to provide such behaviour of js framework, or I totally missed something, anyway I’ll look at the documentation and see how it’s implemented

Comment by CarstepHUN — October 1, 2009


I think by default it uses the Yahoo CDN. Which also combines the files on the fly for you.

Comment by V1 — October 1, 2009

@carstepHUN & V1: Yes it does use Yahoo’s CDN in order to speed up downloads and increase the chance of cache hits. If you want to serve it all from your own server, then you have the option of disabling the combine feature such that each piece is requested individually or you can write your server-side combiner (comeon…how hard is it to write a program that reads a list of files and bundles them all together).

But consider the scenarios:
1) You have a public website. You have everything to gain and nothing to lose by linking to Yahoo’s CDN.
2) You have an intranet site. You’re most likely on a high-bandwidth connection so you’re not going to be hurt by 30 http requests over a pipelined connection.
3) You have a private (SSL-enabled) internet-facing website. This is the one case where building your own combiner makes sense. Again, if building a combiner is difficult for you, you should consider another profession.

Comment by tercero12 — October 1, 2009


“1) You have a public website. You have everything to gain and nothing to lose by linking to Yahoo’s CDN.”

I disagree with this statement slightly. While I certainly see and understand the advantage of linking to Yahoo’s CDN, there is something you lose.
If Yahoo’s site is slow or down, your site is now slow or down too.
Does that happen very rarely? Oh sure, but it does happen.

Also, if you concatenate and minify YUI along with your site javascript too and serve it up in a single script file from your server, you save yourself an HTTP request out to the YUI CDN.

Comment by Sembiance — October 6, 2009

Good starting point:

Comment by CaliPhilli — October 8, 2009

Leave a comment

You must be logged in to post a comment.