Recently, the ASP.NET Roadmap was published on Codeplex. It goes into a good amount of detail about some of the potential future enhancements of ASP.NET Ajax such as DOM databinding and a number of features that are an attempt to catch up to the better Ajax libraries such as jQuery and Dojo. There are a couple of reactions to the document online from Dave Ward and Matt Berseth. I don’t intend to cover the entire document, but rather I will focus on one particular area that I think is unnecessary: Event sinks.
What is an Event Sink?
Basically an event sink makes it possible to set up a listener so that when new events are added to the DOM, the event will automatically be attached to them. For example, if you attach an event to every link in a table when the page is loaded, the event will not normally be propagated to new links that are added to that table. Event sinks are an attempt to aid this problem. Here is an excerpt from the document along with a small code sample.
CSS selector-based event sink so that it becomes possible to set-up an event for all elements that satisfy a given selector at the time when the sink is created and later. This means that events could be generated at the window or component level, without the need to perform clean-up and re-generation when HTML elements are destroyed and re-created and manage their own event hook-ups.
$listen(“hover”, “span[title]”, function(e) { Sys.Debug.trace(this.title); });
There is a Better Solution
Event sinks are completely unnecessary because a better solution already exists: Event delegation. Event delegation works by placing an event handler on a top-level element and then waiting for the event to bubble up. In our example from above, we would put an event handler on the table and then check for when the event source is a link. This works even for new links that are added to the table, which is basically what event sinks plan to do. As an added benefit, it is more efficient because less event handlers need to be created.
The following example is in jQuery, but similar code can be written in straight javascript or any other library. Libraries just make it easier because finding the target is a little bit different in all of the browsers. This is a simple example that just adds a css class to any link that is clicked. This will work even if the link was added to the DOM after page load, which is exactly what we want.
$('.mytable').click(function(){
if ($tgt.is('a'))
{
$tgt.addClass('clicked_link');
}
});
For more on event delegation in jQuery you can check out this post from Learning jQuery about it.
Conclusion
I would recommend using event delegation for attaching events to any group of elements. It is more efficient because you do not need hundreds or thousands of events (which can bring a browser to its knees). It also provides the benefit of automatically handling any new elements that are added to the DOM. This essentially makes ASP.NET event sinks useless and provides another way for less experienced javascript developers to do things in a less efficient way.

July 23rd, 2008 at 7:35 am
The way Bertrand explained $listen in his comment, I believe it will basically amount to a shortcut for exactly what you describe:
http://encosia.com/2008/07/15/the-future-of-aspnet-ajax/#comment-31552
July 23rd, 2008 at 8:16 am
Dave, you’re right - I actually didn’t read the comments before I posted this, although I probably should have.
It’s great that they plan to implement it using event delegation, but my argument that it is essentially a useless feature still stands. I think we should be teaching people to write their event handling code using event delegation instead of using some proprietary syntax. If you learn to use event delegation then the exact same concepts apply no matter what framework you use (they apply with no framework as well).