This article introduces jQuery.on and as the preferred methods for binding events in jQuery 1.7+.

Event binding in jQuery

Prior to jQuery 1.7 there were a few different ways to (un)bind events in jQuery. These methods still exist in 1.7, but they should be considered deprecated.  jQuery 1.7 consolidated these methods into two methods that handle pretty much any event (un)binding use case in a much more efficient manner.

The new sugar and event delegation

jQuery.on  replaces jQuery.bind,, and jQuery.delegate. jQuery.on uses event delegation for binding events, which is good because the end result is less event handlers on your page. Fewer event handlers are good for a couple reasons:

  1. Less memory consumption
  2. Decreased likelihood of memory leaks

Additionally, using event delegation prevents the need to bind and unbind events as dynamic content is replaced within the DOM provided you bind to an element that never leaves the DOM. This means cleaner code and a smaller code base. The front-end is complicated enough already without having to worry about accidently double binding an event or destroying an event handler; when this happens to you for the first time it is very confusing. Prior to using jQuery.on you could use for binding to individual elements using a query selector, which prevented the need to bind and unbind as elements entered and left the DOM, but you still ended up with numerous event handlers. also made stopping event propagation impossible because it would not handle events until they propagated to the top of the document. Up until 1.7 the alternative to jQuery.bind and in 1.4+ was jQuery.delegate. This worked well, but you could only bind to a single event until 1.4.3. Additionally, now there were three methods for event binding each of which had its own unique behavior that could cause confusion when event binding bugs arose in a larger code base where multiple developers had used the different methods. Lastly there was no way to “undelegate” or “unlive” jQuery.delegate and bindings. now solves this issue when used in conjunction with jQuery.on.

Thanks for all that information, but what in the blazes is event delegation and event propagation?

I am glad you asked. Event delegation is basically adding an event listener to a DOM element that contains descendants as opposed to adding event listeners to the individual descendants. Then that event listener examines the events that have bubbled up from its descendants and reacts accordingly. Bubbling is how an event is propagated, which is normalized across browsers by jQuery. A few examples are in order.

// pretend there is a table; what if that table has 250 rows with 10 cells per row?
(function () {   
   $('table td').click(function (e) { // no delegation = 2,500 event handlers!
        console.log('You clicked: '+  $('data-id'));    

   $('table').click(function (e) { // old skool; 1 event handler
        if ( !== 'TD') return;        
        console.log('You clicked: '+  $('data-id'));    
    $('table').delegate('TD', 'click', function (e) { // oldish skool; 1 event handler
        console.log('You clicked: '+  $('data-id'));    
    $('table').on('click', 'TD', function (e) { // cool new skool fool; 1 event handler
        console.log('You clicked: '+  $('data-id'));    

Why are you telling me this?

Firstly, the Viewpoint team just did a major jQuery upgrade, so the majority of developers working on Viewpoint are used to only working with jQuery.bind and jQuery.unbind, so now seemed like a good time to introduce the latest and greatest event binding methods and the concept of event delegation. Secondly, jQuery has provided guidelines for replacing all the old binding methods in their API documentation, so my assumption is that eventually they will be deprecated – start using the new methods now! Thirdly, event delegation in my opinion has been greatly overlooked by most developers who use jQuery exclusively. I am not saying this is true for all jQuery developers, but I have seen enough code, including my own, to feel comfortable making that statement. Lastly, I think the addition of highlights, what many people already know, that single page type web applications are beginning to be recognized as a viable architecture by the community as a whole. Why else would you need the ability to undelegate event bindings? In days of yore web applications refreshed pages constantly, this conveniently cleared out event bindings. Oh yeah, that and there is a whole mess of JavaScript MVC/V type frameworks that have sprung up over the past few years. :)


Event delegation good. Multiple event handlers bad.