Unlocking Event Delegation in jQuery: The Power of the Second Selector

Event Delegation, you might want to check out our resource of Event Handling in JavaScript. For the remainder, enjoy our beginners guide to Event Delegation in jQuery.

While jQuery remains one of the most widely used JavaScript libraries for web development, there’s a frequent point of confusion regarding the use of its .on() event handling function, specifically concerning the optional second selector parameter. Developers often find themselves comparing two approaches:

$('.someclass someselector').on('click', function() {});


$('.someclass').on('click', 'someselector', function() {});

At first glance, these two syntaxes seem to be doing the same thing – binding a click event handler to elements specified by ‘someselector’ that are children of elements with the class ‘someclass’. So, why would we prefer using the second one? The reasons lie in performance, dynamic element handling, and event delegation.

Event Delegation

The primary reason to prefer the second syntax is due to a concept known as event delegation. Event delegation allows us to attach a single event listener, to a parent element, that will fire for all descendants matching a selector, whether those descendants are present now or added in the future.

With the first syntax, jQuery binds the event handler directly to the elements specified by the full selector at the time of code execution. Any element matching the selector that’s added later will not have this event handler.

On the other hand, using the second syntax, jQuery binds the event handler to the elements specified by the first selector (‘.someclass’) only, and then checks if the event target matches the second selector (‘someselector’) at the time the event happens. As a result, this method works even for elements added dynamically after the event is bound, which is a significant advantage for dynamic websites where the DOM can change after page load.

Improved Performance

Besides enabling event binding on dynamically added elements, the second syntax can potentially improve performance.

In the first syntax, when the DOM is large, and there are many elements matching ‘.someclass someselector’, jQuery has to find all these elements and attach an event handler to each one. This can be a time-consuming operation.

In contrast, with the second syntax, the event handler is attached only once, to the ‘.someclass’ element(s), and the ‘someselector’ match is checked on the fly when the event occurs. This results in fewer event handlers in memory and can lead to better performance.


Lastly, the second syntax provides better flexibility. Since the selector is evaluated at run-time rather than at the time of binding, it means you can dynamically change which elements the event applies to without having to manually unbind and rebind the event.

Overall, while both syntaxes can be used to bind event handlers, using the second selector in jQuery’s .on() function is a powerful tool that caters to dynamic, performance-intensive, and flexible web application needs. This approach leverages the concept of event delegation to provide efficient event handling, even on elements added after the page loads. Understanding how these selectors work is key to writing robust and efficient jQuery code.

Whats Next?

You might want to check out our resource of Event Handling in JavaScript.

Leave a Reply