I love you Aaron.

This is still better than attaching the logic to every link to the page on startup. If you have a highly dynamic page (lots of javascript) you’ll have a lot of startup logic that’s setting up search forms, links, effects, etc. You can lower that startup cost dramatically with delegation. The selector taken on its own is very fast – milliseconds – it’s when you stack them up with dozens of startup methods that the page starts to suffer.

That’s a shame it has to run the $$ function again. Seems like it would be a lot faster otherwise. I wonder if there is a way to avoid this, like maybe by using the event target?
…such as:
$(document).addEvent(‘mouseover’, function(e,b){
if(e.target.nodeName==?){
//do something cool
}
} );

Let’s say that you have a page full of links as in the code example above and there are 100 links. You call addEvent on each of these and you run the selector ($$(‘a’)). This isn’t terribly expensive (but you may have a lot of stuff like this going on). When your page loads, this code runs and it creates a demand on the client to process your code immediately. When a user clicks a link, your method is executed immediately and quickly.

Now consider delegation. On startup, you attach an event to the parent (doc.body or something). This is one instruction and it’s nearly instantaneous. Later, a user clicks the document somewhere – anywhere. Now the delegated method fires and the plugin has to see if the user clicked a link and, if so, fire your event. To do this, it must run the same selector that the other example runs ($$(‘a’)) and then compare the element clicked with the elements in the selector *and their children*. This makes for a relatively expensive operation, but there’s two big benefits: 1) you only run this code if the user performs the behavior and 2) if the document has changed (new links are added, for instance) you don’t have to attach more events to the new elements.

So the trade off is a faster start-up that doesn’t need to be managed whenever the content changes in return for a slower event-time. Given that the user may never perform the event in question and given that we tend to put a lot of demand on the client at startup time, the benefit is usually worth it when you have a lot of objects you need to attach events to. It doesn’t make sense for attaching it to a specific dom element – for that you’d just use addEvent.

~~~~~~~~~~~~~~~~~~~~~~~~~

All that said, I actually removed this plugin temporarily. See my post here:

http://www.clientcide.com/code-releases/thoughts-on-element-delegation/

So how much faster is it then?