Howdy YUI, looking fine...ish

I subscribe to some RSS feeds and I've seen some cool videos/posts about YUI3 and it looked kind of interesting. I've always felt like I should be using/checking out YUI more. Everything seems very well thought out, tested, and I love that they have a whole package. Everything from DOM tools, Ajax, CSS Grids all the way to ui widgets. I've always thought they had the best autocomplete widget around from the demo. Tab should complete the current selection, it just should. So I picked up a copy of YUI2.8 Learning the Library and while it's not YUI3, it's a good view into the minds of things and how they fit together. So I decided to port over a work project I'm working on to YUI. It's kind of CMS-y so I want to setup grids just to help flexibility as things go on. (Although...I'm a grid hater for the record) I also want to take advantage of the UI collection for auto complete, progress bar, text editor, treeview and possibly datagrid.

Today was day one and so far so good. It takes a bit of work to get your head moved over from jQuery. I've been using it for a while and really the thought process in jQuery is different. Go find about any tutorial and you'll see things like:

[sourcecode lang="javascript"] // find all the instance of class="important" // and then make sure they're marked with a bolder font $('.important').css('font-weight', 'bold'); [/sourcecode]

This view is kind of against the ideas of mixing logic and template, in a way. I mean this is all view information here. Instead I think I should have things more like:

[sourcecode lang="javascript"] var highlight_important = function (identifier) { var default_id, id;

default_id = '.important';

if (identifier !== undefined) { id = identifier; } else { id = default_id; }

$(id).css('font-weight', 'bold'); }; [/sourcecode]

Now, ideally this would take more config options for just what class property to set and what value to set, all optional of course. And you have this reusable component with a sensible function name you can reuse throughout the app.

This is probably a bad example, but the point is that jQuery comes across as 'find the html and do stuff' where frameworks that come across more verbose/complex, like Dojo and YUI, seem to present things as 'write JS logic' instead.

For instance, I love the idea of the modules in YUI3. I used to just have a custom namespace object like:

[sourcecode lang="javascript"] mystuff = {

'ui': { 'zebra': function () { ... }, },

'form': { 'init': function () { ... },

} [/sourcecode]

This is fine, but I like the idea of the modules you can treat like other YUI modules. For instance my form code turns into something like:

[sourcecode lang="javascript"] YUI.add('myform', function (Y) {

Y.myform = function () { // private property to track the forms we've processed forms_formatted = {};

var that = {};

that.init = function () { Y.myform.maxlabels(); },

that.dosomething = function () { ... }

return that; }(); }, '0.0.1', { requires: ['node'] });

// and use it like var login_page = function () { YUI().use("node", "yui2-button", 'myform', function(Y) {

var Y2 = Y.YUI2;

//YUI 2 implementation code var button = new Y2.widget.Button("submit");

// init the form ui tweaks Y.myform.init(); }); }; [/sourcecode]

This also shows off how I can do things like include the YUI2 widgets.

So people are asking "Why use YUI over jQuery" and it really comes down to 'total package' with the overall completeness of things, 'well thought outness' of the library. In reading things I'm always hitting points like "man, that's a really good way to do/handle that". Finally, I want to try out and seem to like how it makes you 'think' when writing the code.

Will it stick, who knows, but I've learned enough JS to want to try out something a bit higher up. I consider it a bit like going from webob to Pylons. They're both JS underneath and all, but one includes a lot more bits than the other at the cost of some framework complexity.