Lambda the Ultimate

This is why Javascript is a good thing--people are seeing the power of higher-order functions, and having fun using them liberally. Look, a doubly-nested closure!

Actually, I think it would simplify his idiom if he eliminated one of the levels of nesting and abstracted away some of the mutation from the client. Instead of:

var myrules = {
    'b.someclass' : function(element) {
        element.onclick = function() { ... };
    },
    '#someid u' : {
        element.onmouseover = function() { ... };
    }
};

he could change it so that the selectors get themselves mapped to associative arrays, which in turn map the event name to the event handler:

var myrules = {
    'b.someclass' : {
        onclick : function() { ... }
    },
    '#someid u' : {
        onmouseover : function() { ... }
    }
};

Now it's that much more declarative. The client doesn't lose anything by eliminating the lexically scoped element variable, because they can access the DOM node via the dynamically scoped this, which he used in his examples anyway.

The library can easily take responsibility for setting the event handlers by using the for .. in form to iterate over the properties of the associative array of event handlers, which moves the mutation into the library and away from the grubby hands of the client.

for (var p in eventHandlerArray) {
    element[p] = eventHandlerArray[p];
}

Another cool use of this "behavior" idea is that you can use CSS classes like traits or mixins, adding behavior to any node you like. You can always give any HTML node multiple classes by separating them with spaces:

<div class="codeSnippet italicized clickable"> ... </div>

So you can combine these behaviors (almost) modularly.

If you have multiple behaviors competing for the same properties, all bets are off. For example, if a clickable property overwrites the onlick property, and a draggable behavior overwrites the onclick property, boom! whoever gets there first destroys the other one.

This means the interface of a behavior includes the set of properties it overrides, and it's probably most reasonable to say that a well-formed composition of behaviors can never combine behaviors that override the same property.

Alternatively, if you use functional composition to extend event handlers instead of overwriting them, you can actually compose behaviors. (But the order of composition should probably not affect what the behaviors do--just ask the AOP folks.) However, it would be harder to remove a behavior later.

If you want the ability to remove behaviors you've added, then you could make a behavior be a function that has a "registry" property (all functions are objects in Javascript, so they can contain properties). The body of the function would never change; it would always just iterate over the registry and apply each registered behavior in turn. Then adding and removing behaviors would go through the registry.

I blogged about this a bit before it appeared on LtU. I'm repeat the interesting bits of my comments here:

This gives cleaner code, though I'm not sure how useful it will be in practice, for two reasons:

• It will be slower than just writing the event handlers directly in the HTML. How much slower I haven't measured, so this may not be a problem.
• I don't write much Javascript directly (except when trying out new ideas). Instead I tend to generate it (along with HTML) from other sources, so achieving a separation between Javascript and HTML isn't an issue for me.

However I don't want to give a negative view of this library. I think it is really neat, and it has interesting similarities to Aspect-oriented programming (AOP).

Dave has said more about the AOP relationships here, on his blog, and on Untyping.

I've implemented a prototype of what I described above. Event handlers are described in a more declarative style (as maps from event names to handler functions), and they are combined with composition, rather than overridden.

Looks quite a lot like the functionality provided by [bind]/[bindtags] in Tk for over a decade. The pattern matching here is a bit more sophisticated (Tk allows binding to an individual instance or a class), but other than that I don't see much difference. e.g. in Tk I could do:

bind MyClass <Button-1> ...
bind MyClass <Enter> ...
bind MyClass <Leave> ...
somewidget .foo -class MyClass ...

You can trivially go from that to something more like:

widgetclass MyClass {
    <Button-1>  { ... }
    <Enter>     { ... }
    <Leave>     { ... }
}

Why the fuss?