What's the difference between jQuery.bind() and jQuery.on()?

Question

And why is .on() now preferred in jQuery 1.7?

[Here](http://blog.jquery.com/2011/11/03/jquery-1-7-released/) is the blog entry wherein the jQuery team describes `.on()` and `.off()`. — Pointy, Feb 02 '12 at 14:16
The summary of it being: "The new .on() and .off() APIs unify all the ways of attaching events to a document in jQuery — and they’re shorter to type!" — Dan Blows, Feb 02 '12 at 14:21

jfriend00 · Accepted Answer · 2012-02-02T14:45:56.650

.on() now offers a combination of .live(), .delegate() and .bind() all in one unified method. You can get the behavior of any of those three just by how you use the arguments to .on().

These pairs are functionally the same:

// events bound directly to the object they occur on
$('.button').on('click', fn);
$('.button').bind('click', fn);

// events intercepted after bubbling up to a common parent object
$('.container').on("click", '.button', fn);
$('.container').delegate('.button', "click", fn);

More info is described in a jQuery blog entry.

Before unifying these separate functions, jQuery had multiple different implementations. Now, .on() is the superset function and .bind(), .live() and .delegate() all just call .on() in their implementation so there is now only one implementation of the actual event handling. So, from that standpoint, it was also a code cleanup and streamlining issue. Similarly, .die(), .undelegate() and .unbind() just call .off() now rather than have separate implementations.

Note: .live() has been deprecated for all versions of jQuery because it's just a special case of intercepting all the bubbled events on the document object so it can be easily replaced with either .delegate() or .on() and when lots of events were all being handled on the document object, it could become a performance problem checking lots of selectors on every event. It's much more efficient to hook a delegated event like this to a common parent that is much closer to where the event occurs than put them all on the document object (thus why .live() is not good to use).

From the jQuery 1.7 source, you can see how all these functions just now call .on() and .off():

bind: function( types, data, fn ) {
    return this.on( types, null, data, fn );
},
unbind: function( types, fn ) {
    return this.off( types, null, fn );
},

live: function( types, data, fn ) {
    jQuery( this.context ).on( types, this.selector, data, fn );
    return this;
},
die: function( types, fn ) {
    jQuery( this.context ).off( types, this.selector || "**", fn );
    return this;
},

delegate: function( selector, types, data, fn ) {
    return this.on( types, selector, data, fn );
},
undelegate: function( selector, types, fn ) {
    // ( namespace ) or ( selector, types [, fn] )
    return arguments.length == 1? this.off( selector, "**" ) : this.off( types, selector, fn );
},

score 3 · Answer 2 · answered Feb 02 '12 at 14:22

3

The MAIN difference is that .bind requires the element (selector) exist AT THE TIME it gets attached, whereas .on does not have that requirement, and .on frankly has better/more elegant syntax in my opinion. See the documentation first paragraph http://api.jquery.com/bind/

answered Feb 02 '12 at 14:22

Mark Schultheiss

32,614
12
69
100

2

In this use of `$(selector).on('click', fn)`, the selector must still exist at the time it gets attached. In this version `$(parentselector).on('click', selector, fn)`, the `parentselector` must exist at the time it gets attached, but the other `selector` does not have to exist yet. It is important to understand what must exist and what can be created later. – jfriend00 Feb 02 '12 at 14:37
Yes, thank you for the clarification, and always,` $(document).on(` is available for attachement as your "parentselector" in your example. – Mark Schultheiss Feb 02 '12 at 14:53
Yes, but using `$(document).on()` for lots of events causes performance issues. That's why `.live()` has been deprecated because that's what it did. It's much better to pick a parent selector much closer to the actual event that isn't the same selector used for lots of other types of events. – jfriend00 Feb 02 '12 at 14:55
@jfriend00 - true, but I did not intend to fully document .bind() .on() and .live() here but merely to point out the major difference between .bind() and .on() – Mark Schultheiss Feb 02 '12 at 16:00

score 1 · Answer 3 · answered Feb 02 '12 at 14:16

1

The old method was a bit messy - the difference between live(), delegate() and bind() was not clear. By making on() the function that handles attaching any event, regardless of whether it exists or not, it's just easier to work with.

Before now, live() was a lot slower than the new on() function, hence why you had to choose between bind() and live().

answered Feb 02 '12 at 14:16

Dan Blows

20,846
10
65
96

Given the correct parameters that will mimic the functionality of `live`, I think `on` is just as slow. – James Montagne Feb 02 '12 at 14:49
I personally haven't profiled it, so can't say, but according to the jQuery post, it is much quicker than the `live()` implementation. Of course, they would say that, but it might be true. – Dan Blows Feb 02 '12 at 14:50
Oh okay, I think I misread you slightly. They did say they improved event delegation. – James Montagne Feb 02 '12 at 14:55

What's the difference between jQuery.bind() and jQuery.on()?

3 Answers3

Linked