To me it underlines why I find YUI3 daunting. The ui widgets they have seem elegant and certainly more comprehensive than jquery + jQUI - but the contrast in the syntax has so far kept me from delving too deep. But I've been working with jq long enough that it's all fairly intuitive and natural to me - perhaps a few months with YUI would give me the same level of comfort there.

Ask HN: If you actually prefer working with YUI3, tell me why?

If you're going to write large scale widgets, YUI is a better suited choice because of it's already large collection of A-grade supported widgets, and emphasis on reuse. Yahoo! has put a ton of work into making sure their widgets are accessible by the disabled.

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.

Building our application, we have moved through the various JS libraries, including JQuery, and now stick with YUI.

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.

Empty jQuery sets are truthy. The page gets this doubly wrong when it says an empty list is returned (instead of the 'Array-like' jQuery set.)

Check the length property of a returned jQuery set if truthiness really matters.

Ah! I will verify and correct. Thanks.

JavaScript is weird about truthyness / falsyness of arrays:

  if([] == false){
    // this code runs
  }

  if( [] ) {
    // this code also runs
  }

  if([] == true){
    // this code doesn't run
  }

From http://nfriedly.com/techblog/2009/06/advanced-javascript-ope...

Does YUI3 have a similar resource footprint to YUI2?

At my job we're transitioning away from YUI to jQuery UI partially because for what we're using–a slider and a dialog–it takes an order of magnitude more included JavaScript (a few hundred KB minified)

YUI3 is MUCH smaller than YUI2. The rewrite was mostly about addressing this exact issue though everything-in-a-closure and pervasive query API were also major reasons.

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.

Why?

PS: Is YUI3 gaining traction? Has features missing in jQuery? ...

I was porting an app prototype from jQuery to YUI3, and started taking notes on equivalent snippets of code. It seems to be useful, so I wrote it up.

I was wondering what the business case was for the switch. I'm evaluating both for a project of mine right now. (I use GXT for another project, but that won't fly for this one.)

The app was a mix of yui2 (widgets) and jq (selectors). Yui3 has both.

thanks for the writeup. It will help when I'm moving yui-flot to yui3

I think it's interesting to see the different approaches used by jQuery and YUI. Plus if you know jQuery, you can get a good sense of YUI's style just by going down the list and comparing syntax. This also pointed out a few things that YUI can do out of the box that jQuery can't, such as cross-domain requests via a flash helper.