Should all jquery events be bound to $(document)?

Question

Where this is coming from

When I first learned jQuery, I normally attached events like this:

$('.my-widget a').click(function() {
    $(this).toggleClass('active');
});

After learning more about selector speed and event delegation, I read in several places that "jQuery event delegation will make your code faster." So I started to write code like this:

$('.my-widget').on('click','a',function() {
    $(this).toggleClass('active');
});

This was also the recommended way to replicate the behavior of the deprecated .live() event. Which is important to me since a lot of my sites dynamically add/remove widgets all the time. The above doesn't behave exactly like .live() though, since only elements added to the already existing container '.my-widget' will get the behavior. If I dynamically add another block of html after that code has ran, those elements will not get the events bound to them. Like this:

setTimeout(function() {
    $('body').append('<div class="my-widget"><a>Click does nothing</a></div>');
}, 1000);

What I want to achieve:

1. the old behavior of .live() // meaning attaching events to not yet existent elements
2. the benefits of .on()
3. fastest performance to bind events
4. Simple way to manage events

I now attach all events like this:

$(document).on('click.my-widget-namespace', '.my-widget a', function() {
    $(this).toggleClass('active');
});

Which seems to meet all my goals. (Yes it's slower in IE for some reason, no idea why?) It's fast because only a single event is tied to a singular element and the secondary selector is only evaluated when the event occurs (please correct me if this is wrong here). The namespace is awesome since it makes it easier to toggle the event listener.

My Solution/Question

So I'm starting to think that jQuery events should always be bound to $(document).
Is there any reason why you would not want to do this?
Could this be considered a best practice? If not, why?

If you've read this whole thing, thank you. I appreciate any/all feedback/insights.

Assumptions:

1. Using jQuery that supports .on() // at least version 1.7
2. You want the the event to be added to dynamically added content

Readings/Examples:

1. http://24ways.org/2011/your-jquery-now-with-less-suck
2. http://brandonaaron.net/blog/2010/03/4/event-delegation-with-jquery
3. http://www.jasonbuckboyer.com/playground/speed/speed.html
4. http://api.jquery.com/on/

Meeting

possible duplicate of Why not take Javascript event delegation to the extreme? – Tenebrae

Answer 1

No - you should NOT bind all delegated event handlers to the document object. That is probably the worst performing scenario you could create.

First off, event delegation does not always make your code faster. In some cases, it's is advantageous and in some cases not. You should use event delegation when you actually need event delegation and when you benefit from it. Otherwise, you should bind event handlers directly to the objects where the event happens as this will generally be more efficient.

Second off, you should NOT bind all delegated events at the document level. This is exactly why .live() was deprecated because this is very inefficient when you have lots of events bound this way. For delegated event handling it is MUCH more efficient to bind them to the closest parent that is not dynamic.

Third off, not all events work or all problems can be solved with delegation. For example, if you want to intercept key events on an input control and block invalid keys from being entered into the input control, you cannot do that with delegated event handling because by the time the event bubbles up to the delegated handler, it has already been processed by the input control and it's too late to influence that behavior.

Here are times when event delegation is required or advantageous:

• When the objects you are capturing events on are dynamically created/removed and you still want to capture events on them without having to explicitly rebind event handlers every time you create a new one.
• When you have lots of objects that all want the exact same event handler (where lots is at least hundreds). In this case, it may be more efficient at setup time to bind one delegated event handler rather than hundreds or more direct event handlers. Note, delegated event handling is always less efficient at run-time than direct event handlers.
• When you're trying to capture (at a higher level in your document) events that occur on any element in the document.
• When your design is explicitly using event bubbling and stopPropagation() to solve some problem or feature in your page.

---

To understand this a little more, one needs to understand how jQuery delegated event handlers work. When you call something like this:

$("#myParent").on('click', 'button.actionButton', myFn);

It installs a generic jQuery event handler on the #myParent object. When a click event bubbles up to this delegated event handler, jQuery has to go through the list of delegated event handlers attached to this object and see if the originating element for the event matches any of the selectors in the delegated event handlers.

Because selectors can be fairly involved, this means that jQuery has to parse each selector and then compare it to the characteristics of the original event target to see if it matches each selector. This is not a cheap operation. It's no big deal if there is only one of them, but if you put all your selectors on the document object and there were hundreds of selectors to compare to every single bubbled event, this can seriously start to hobble event handling performance.

For this reason, you want to set up your delegated event handlers so a delegated event handler is as close to the target object as practical. This means that fewer events will bubble through each delegated event handler, thus improving the performance. Putting all delegated events on the document object is the worst possible performance because all bubbled events have to go through all delegated event handlers and get evaluated against all possible delegated event selectors. This is exactly why .live() is deprecated because this is what .live() did and it proved to be very inefficient.

---

So, to achieve optimized performance:

1. Only use delegated event handling when it actually provides a feature you need or increases performance. Don't just always use it because it's easy because when you don't actually need it. It actually performs worse at event dispatch time than direct event binding.
2. Attach delegated event handlers to the nearest parent to the source of the event as possible. If you are using delegated event handling because you have dynamic elements that you want to capture events for, then select the closest parent that is not itself dynamic.
3. Use easy-to-evaluate selectors for delegated event handlers. If you followed how delegated event handling works, you will understand that a delegated event handler has to be compared to lots of objects lots of times so picking as efficient a selector as possible or adding simple classes to your objects so simpler selectors can be used will increase the performance of delegated event handling.

Intercession

Awesome. Thank you for the quick and detailed description. That makes sense that the event dispatch time will increase by using .on() but I think I'm still struggling deciding between the increased event dispatched time vs initial page processing team. I am generally for decreased initial page time. For example, if I have 200 elements on a page (and more as events happen), it's about 100 times more expensive at the initial load (since it has to add 100 event listeners) rather than if I add a singular event listener onto the parent container link – Meeting

Also wanted to say that you convinced me - Do not bind all events to $(document). Bind to the closest none-changing parent as possible. I guess I'll still have to decide on a case-by-case basis when event delegation is better than directly binding an event to an element. And when I need events tied to dynamic content (that don't have a non-changing parent) I guess I'll keep doing what @Vega recommends below and simply "bind the handler(s) after the contents get inserted into (the) DOM", using jQuery's context parameter in my selector. – Meeting

@user1394692 - if you have a lot of nearly identical elements, then it may make sense to use delegated event handlers for them. I say that in my answer. If I had a giant 500 row table and had the same button in every row of a particular column, I would use one delegated event handler on the table to serve all the buttons. But if I had 200 elements and they all needed their own unique event handler, installing 200 delegated event handlers isn't any faster than installing 200 directly bound event handlers, yet the delegated event handling might be a lot slower upon event execution. – Intercession

You are perfect. Totally agree! Do I understand that this is the worst thing I can do - $(document).on('click', '[myCustomAttr]', function () { ... }); ? – Mitis

Using pjax/turbolinks poses an interesting problem since all elements are dynamically created/removed (apart from the first page load). So is it better to bind all events once to the document, or bind to more specific selections on page:load and unbind these events on page:after-remove? Hmmm – Jubal

Good answer. This still holds for jQuery because it performs delegation in an inefficient way, in order to support IE8. But for vanilla JS and modern browsers, it looks like you should choose event delegation instead, and binding all events to document seems less outrageous. – Rusty

Answer 2

Event delegation is a technique to write your handlers before the element actually exist in DOM. This method has its own disadvantages and should be used only if you have such requirements.

When should you use event delegation?

1. When you bind a common handler for more elements that needs same functionality. (Ex: table row hover)
   • In the example, if you had to bind all rows using direct bind, you would end up creating n handler for n rows in that table. By using delegation method you could end up handling all those in 1 simple handler.
2. When you add dynamic contents more frequently in DOM (Ex: Add/remove rows from a table)

Why you should not use event delegation?

1. Event delegation is slower when compared to binding the event directly to element.
   • It compares the target selector on every bubble it hits, the comparison will be as expensive as it is complicated.
2. No control over the event bubbling until it hits the element that it is bound to.

PS: Even for dynamic contents you don't have to use event delegation method if you are bind the handler after the contents get inserted into DOM. (If the dynamic content be added not frequently removed/re-added)

Repeal

Answer 3

I'd like to add some remarks and counterarguments to jfriend00's answer. (mostly just my opinions based on my gut feeling)

No - you should NOT bind all delegated event handlers to the document object. That is probably the worst performing scenario you could create.

First off, event delegation does not always make your code faster. In some cases, it's is advantageous and in some cases not. You should use event delegation when you actually need event delegation and when you benefit from it. Otherwise, you should bind event handlers directly to the objects where the event happens as this will generally be more efficient.

While it's true that performance might be slightly better if you are only going to register an event for a single element, I believe it doesn't outweigh the scalability benefits that delegation brings. I also believe browsers are (going to be) handling this more and more efficiently, although I have no proof of this. In my opinion, event delegation is the way to go!

Second off, you should NOT bind all delegated events at the document level. This is exactly why .live() was deprecated because this is very inefficient when you have lots of events bound this way. For delegated event handling it is MUCH more efficient to bind them to the closest parent that is not dynamic.

I kind of agree on this. If you are 100% sure that an event will only happen inside a container, it makes sense to bind the event to this container, but I would still argue against binding events to the triggering element directly.

Third off, not all events work or all problems can be solved with delegation. For example, if you want to intercept key events on an input control and block invalid keys from being entered into the input control, you cannot do that with delegated event handling because by the time the event bubbles up to the delegated handler, it has already been processed by the input control and it's too late to influence that behavior.

This is simply not true. Please see this codePen: https://codepen.io/pwkip/pen/jObGmjq

document.addEventListener('keypress', (e) => {
    e.preventDefault();
});

It illustrates how you can prevent a user from typing by registering the keypress event on the document.

Here are times when event delegation is required or advantageous:

When the objects you are capturing events on are dynamically created/removed and you still want to capture events on them without having to explicitly rebind event handlers every time you create a new one. When you have lots of objects that all want the exact same event handler (where lots is at least hundreds). In this case, it may be more efficient at setup time to bind one delegated event handler rather than hundreds or more direct event handlers. Note, delegated event handling is always less efficient at run-time than direct event handlers.

I'd like to reply with this quote from https://ehsangazar.com/optimizing-javascript-event-listeners-for-performance-e28406ad406c

Event delegation promotes binding as few DOM event handlers as possible, since each event handler requires memory. For example, let’s say that we have an HTML unordered list we want to bind event handlers to. Instead of binding a click event handler for each list item (which may be hundreds for all we know), we bind one click handler to the parent unordered list itself.

Also, googling for performance cost of event delegation google returns more results in favor of event delegation.

When you're trying to capture (at a higher level in your document) events that occur on any element in the document. When your design is explicitly using event bubbling and stopPropagation() to solve some problem or feature in your page. To understand this a little more, one needs to understand how jQuery delegated event handlers work. When you call something like this:

$("#myParent").on('click', 'button.actionButton', myFn); It installs a generic jQuery event handler on the #myParent object. When a click event bubbles up to this delegated event handler, jQuery has to go through the list of delegated event handlers attached to this object and see if the originating element for the event matches any of the selectors in the delegated event handlers.

Because selectors can be fairly involved, this means that jQuery has to parse each selector and then compare it to the characteristics of the original event target to see if it matches each selector. This is not a cheap operation. It's no big deal if there is only one of them, but if you put all your selectors on the document object and there were hundreds of selectors to compare to every single bubbled event, this can seriously start to hobble event handling performance.

For this reason, you want to set up your delegated event handlers so a delegated event handler is as close to the target object as practical. This means that fewer events will bubble through each delegated event handler, thus improving the performance. Putting all delegated events on the document object is the worst possible performance because all bubbled events have to go through all delegated event handlers and get evaluated against all possible delegated event selectors. This is exactly why .live() is deprecated because this is what .live() did and it proved to be very inefficient.

Where is this documented? If that's true, then jQuery seems to be handling delegation in a very inefficient way, and then my counter-arguments should only be applied to vanilla JS.

Still: I would like to find an official source supporting this claim.

:: EDIT ::

Seems like jQuery is indeed doing event bubbling in a very inefficient way (because they support IE8) https://api.jquery.com/on/#event-performance

So most of my arguments here only hold true for vanilla JS and modern browsers.

Rusty

Answer 4

Apparently, event delegation is actually recommended now. at least for vanilla js.

https://gomakethings.com/why-event-delegation-is-a-better-way-to-listen-for-events-in-vanilla-js/

"Web performance # It feels like listening to every click in the document would be bad for performance, but it’s actually more performant than having a bunch of event listeners on individual items."

Reddish