1

I wonder if many Event Listeners take on perfomance.

for example if i have 50 Elements that listen on click events, does it make a change if i have 50 Event Listeners for each element one listener like so

$('#one').on("click",function(){ // do something; });
$('#two').on("click",function(){ // do something else; });
...
$('#fifty').on("click",function(){ // do something else; });

or just one event listener

$('.listen_to_click').on("click",function(){ 
// handle action here depending on data attribute or something else 
});

//or does jQuery add here an event listener internally on every .listen_to_click element so that it doesn´t make any change at all -  in this case does it change when you do like so

$('body').on("click",'.listen_to_click',function(){
 // handle action here depending on data attribute or something else
 });

or when you use plain javascript do something like this

document.getElementByTagName('body').addEventListener("click",function(e){
// handle action on e.target or something else
});

instead of

document.getElementById('one').addEventListener("click",function(e){
    // do something
    });
document.getElementById('two').addEventListener("click",function(e){
    // do something else
    });
...
document.getElementById('fifty').addEventListener("click",function(e){
    // do something else
    });

so what i want to know is.. does it make any sense in performance

Thanks

Sven Delueg
  • 1,001
  • 11
  • 23
  • 4
    Probably makes sense to test it. jsperf.com. – j08691 May 01 '14 at 21:00
  • Vanilla JS will always be faster. This is fact and also common sense. Anything lower level will faster than the high level abstracted wrapper code. – Ryan May 01 '14 at 21:01
  • @RPM sure Vanilla JS is always faster - i EDIT the question.. because i wanted to know if does make a change if you have one listener on the body for example and handle your action inside this one function – Sven Delueg May 01 '14 at 21:07
  • 2
    I'd suggest that you read these related answers that discuss tradeoffs when dealing with lots of events: [Should all jquery events be bound to $(document)?](http://stackoverflow.com/questions/12824549/should-all-jquery-events-be-bound-to-document/12824698#12824698), [JQuery Event Handlers - What's the “Best” method](http://stackoverflow.com/questions/9730277/jquery-event-handlers-whats-the-best-method/9730309#9730309), [Why not take Javascript event delegation to the extreme?](http://stackoverflow.com/questions/9711118/why-not-take-javascript-event-delegation-to-the-extreme/9711252#9711252). – jfriend00 May 01 '14 at 21:22

1 Answers1

2

Adding it to each element one at a time vs adding it to 50 at once makes no difference after the event is bound. You may be able to do a jsperf to prove that doing one or the other binds the events faster, but the actual handling of the events will not be any different assuming that in both cases you are binding directly to the elements and not doing delegation.

On the other hand, using event delegation such as binding a click event on the body and testing if the event.target matches a selector will be slower than binding the click event directly to the element because the event will have to bubble up to the body before it can be handled. It will also have to execute all handlers that happen before it, so that can impact the performance too. That's why when using event delegation it's best to set the delegate target as close to the event target as possible.

Kevin B
  • 94,570
  • 16
  • 163
  • 180
  • 1
    "That's why when using event delegation it's best to set the delegate target as close to the event target as possible" Precisely. `$(document).on('click', '#my-dv');` vs `$('#container').on('click', '#my-db');` – Ryan May 01 '14 at 21:14
  • ok - and what is in the case if i have only one binded event on the body and handle the operation inside one handler function -- i mean i can check for example the ID or an data-attribute of the current target and handle the action on this parameter – Sven Delueg May 01 '14 at 21:16
  • The bubbling and capturing should not be a problem, as this is done all the time anyway, not matter if event listeners are attached or not. The biggest problem with event delegation is that the selectors need to be matched against the event taget every time the event happens. – t.niese May 01 '14 at 21:18
  • @t.niese thanks for that - the only thing i still think about is... so it is no problem (performance) or even an issue at all to have maybe 200 eventlisteners in on application instead of one. – Sven Delueg May 01 '14 at 21:26
  • what i mean is.. i understand event delegation and on the other hand what RPM mentioned... for me it seems that you have to make a well balanced mix of event delegation and direct event binding - is this right? – Sven Delueg May 01 '14 at 21:29
  • 2
    The number of event handlers that exist is somewhat irrelevant. what is important is how often they get triggered. yes, an event binding is more data taking up more memory, but that won't impact performance unless it's an extreme case. (whether or not 200 is an extreme case will depend on the resources available to the client) – Kevin B May 01 '14 at 21:30
  • ok.. this and @jfriend00 mentioned links did it for me.. thanks a lot – Sven Delueg May 01 '14 at 21:34
  • I guarantee though that it will be faster to bind one event handler to the tbody than it would be to bind one to each of 200 buttons in the last table cell of each row. However, the handling of each click will be slightly slower (nanoseconds slower, in other words, not significant) – Kevin B May 01 '14 at 21:34