A Rosetta Stone for jQuery & YUI3

In addition, YUI3 can dynamically load resources, which can be very beneficial if you have a large collection of widgets and only want to load the code for them when it's necessary.

I love both libraries, there are trade offs with each, which is why evaluating them for your project is a wise decision, if only to understand the strengths and weaknesses.

The overwhelming reason is we need guaranteed support for all the advanced features we want to build on. JQuery is a set of element actions/seclectors, but lacks plug-ins/widgets with the core library. JQuery has active developers all over the web building plug-ins that are amazing. But if we incorporate with the plug-ins and find a bug, we have to hope the plug-in project is still active and will receive support.

With YUI, we can use their supported widgets, file bugs and know we will receive attention from the YUI developers.

Also, note the author's choice of code is not always the simplest and could be better written.

They basically took a fair number of the modules in YUI2 and sliced them up into very small functional bits (e.g. some of the modules are a ~80 LoC). This allows you to do fine grained loading of exactly what you need. Most apps I put together in yui3 are smaller than the jQuery equivalent because they're put together using only what they need out of the lib.

There's a downside to this. The AlloyUI set of widgets was previewed this week which are built by a 3rd party but done using the same patterns core yui3 uses. The AlloyUI autocomplete widget does 58 HTTP requests pulling in modules. This is, of course, completely unacceptable for production. The way around it is a piece of server infrastructure called a combo loader. The combo loader takes a particular url crafted by the yui loader and glues all the requested modules+dependencies together in one request. By default yui will use the Yahoo CDN which can combo-load the core library plus whatever 3rd party extensions are in the yui-gallery. You can also pre-bake dependencies using a build script, but combo loading seems more pervasive.

The other thing they did was change how the widgets work together. Now a widget just does what it says. As an example, the dialog will just display a div at a certain position. If you want functionality like being able to pull the contents in via XHR or animate the showing and hiding, you have to specifically include that and plug it in to activate that functionality on the widget. You might wind up with a couple hundred K still but you pulled that in yourself rather than having the library pull it in just in case you might want it.

One thing they mentioned on their forum is that they might add support for pulling in dependencies on a per-browser basis so if you're on IE6 you get the extra shim code that isn't needed on, say Safari 4. Anyway, it's ongoing.

The main drawback to the library is that the community is rather small compared to jQuery and YUI2.