For a while, we used Prototype at work. My choice. I was familiar with it from Ruby on Rails, script.aculo.us had effects I wanted to work with, and Dojo wasn’t quite ready yet (and was overkill for our needs). When Yahoo! released YUI, it did not take long for me to switch. Yahoo!’s attitude toward accessibility and toward graded browser support is much more in line with my philosophy. And by “in line with” I mean “identical.” Throw in thorough documentation and I’m sold. We still have discussions about framework choices, as the space changes a lot and different projects have different needs, but let’s save topic that for another day.

What I do miss from Prototype is the little bits of syntactic sugar sprinkled throughout. I could write this:

Event.observe('myLink', 'click', doSomething)

but it feels a whole lot more natural to write this:

$('myLink').observe('click', doSomething)

Instead of registering an event handler with some great EventHandlerManager in the sky, which is what the first bit of code feels like, I’m instead asking an object to observe itself and do something if an event happens. Technically that’s not necessarily what happens, but that’s what syntactic sugar is all about. I shouldn’t always have to care what really happens.

(I should confess here that I diverge from the mainstream in my funny ideas about object-oriented programming. I have been heavily influenced by David West’s Object Thinking, which hearkens back to OOP as it originally emerged, not as it was co-opted by procedural programmers who didn’t quite get it. I also readily accept that there are different ways of doing OOP “right.” Again, that’s a topic for another day.)

YUI doesn’t have any such nifty syntax.

YAHOO.Event.addListener('myLink', 'click', doSomething)

That’s what you’ve got. Okay, there are aliases:

YAHOO.Event.on('myLink', 'click', doSomething)

There are optional parameters let you easily pass an object as parameters to the callback, and redefine the scope of this inside that handler:

YAHOO.Event.addListener('myLink', 'click', doSomething, obj, override)

These are small touches that make a difference and that reinforce my pleasure in using YUI. But still, after a while the syntax feels stilted. Unnatural. Reading the code that I’m seeing turn up in some of our projects, including my own, I can see the code growing out of control. It’s easy to build up convoluted and verbose code that just does not make sense. It’s not YUI’s fault, but in the hands of someone who doesn’t understand the language, it’s not pretty.

Today, inspired by Adam McCrea’s JavaScript metaprogramming presentation, I took some code that was quickly becoming ugly and hard to follow, and turned it into a little domain specific language.

toggle(checkboxes).when('myLink').is('clicked')

I work with a bunch of people who hate JavaScript, mostly because they misunderstand it and dismiss it as a toy. Every time I write JavaScript, I’m delivering my coworkers code that not only will be used as a model, but that reflects on the language itself. If my code is inelegant, JavaScript looks bad. Worse than it deserves, anyway. :)

Today’s work feels good. Not only should it be really, really clear how to use the above code, all the code behind it is much more cleanly designed, and uses YUI to good advantage. It’s been a good day.