Question

I am in the mist of optimising a rather large piece of jQuery code. I need help.

Specifically, I have many elements that I want draggable. I have decided to use event delegation to minimise loading time, as briefly discussed here. The problem is that run-time performance is slightly damaged, because the browser has to initialise the dragging at run-time.

Is it possible to use delegation during page loading then, if the browser is inactive, have the elements little by little made draggable through binding? (Some sort of clever asynchronous binding.) That way, I would get high loading and high run-time performance.

Or is there yet an even better approach?

Answer 1

You should simply stick to delegation. There should only be a minimal/near non-existent performance penalty for handling the event after it has bubbled up. However, there absolutely will be a penalty to pay if you end up binding the handler to a lot of elements as you indicate you’re doing, not matter how slowly you do it. Is there a specific other concent you don’t see the delegate handling as the complete solution? I’ve been sitting here thinking for a bit but I can’t recall any specific edge case issues that crop up with that, aside from ie7 an below’s failure at event bubbling, in which case you’re screwed in all ways anyway. You should just be adding a single handler to parent, or the window, and I can’t see how that would cause issues at any point.

$(selector).live("event names", handler);

which is the same as

$(window).delegate(selector, "event names", handler)

Both of which only bind a single event handler to a single DOM element.

I’ve reread the question a few times and I’m not sure if you’re just not firm on how event delegation works or if I missed something in the reading, so apologies if I missed it.

When you use a delegate handler what you do is create an event listener on a common parent element. DOM events bubble up through the parent chain to window which allows you to have one function listening for events on a lot of elements (if you bind a handler on window then you get pinged on every single event firing of that type that isn’t explicitly stopped from bubbling). An event will identify which element it originally was targeting, so the delegate handler just checks all event targets against the ones it’s been assigned to, and then routes them when it finds an applicable event. That’s as simple something like targetElement["on"+event.name].call(targetElement, event) (libraries like jQuery do some additional stuff for you but that’s the gist). Monitoring the events like this costs nearly nothing so that’s not going to cause any issues.

The benefits are multifold but the two big ones are:

1. You only have one event handler at one DOM insertion point consuming memeory and cpu cycles. With the way events bubble and lots of other issues, having copies of an event handler watching different elemnts is always worse performing, significantly worse.

2. You can bind events to elements that don’t exist yet. Since you can identify them through characteristics such as selectors, you can set up a handler based on that stuff (this normally being how it’s done anyway). If you want to bind an event to a specific element without using delegate handling then you have to have an element creation monitoring and event binding handler, to bind handlers to newly created elements which is a huge overhead as well.

There’s a handful of exceptions where there are issues caused from delegation. One which arises in IE8 and below causes problems with mouse enter and leave to not fire correctly. These are the cases which demonstrate the need to use something like jQuery specifically when it comes to normalizing DOM quirks. At this point though if you’re not trying to support