

Differences Between jQuery .bind() vs .live() vs .delegate() vs .on() - elijahmanor
http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html

======
jd
What I really like about the old style bind/live/delegate is that it's so
grep-able. The new on()-based API makes it much harder to search through a
codebase.

In addition, when you see something like:

    
    
        $('.table a').click(function() { ... } )
    

it immediately looks wrong, because there are probably multiple links in the
table. Wrong code that looks wrong is great, because you can then refactor it
as you come across it. But now you have to check if a second selector argument
is passed to "on", to see if unnecessary event handlers are created.

~~~
strickjb9
This is also my biggest grip with the new .on(). I can't quickly look through
code anymore since .on() can take on different meanings based on the arguments
passed. When jQuery 1.7 was released I commented on this on the release notes
page, I wasn't well received. It's refreshing to know that others feel the
same way...

[http://blog.jquery.com/2011/11/03/jquery-1-7-released/#comme...](http://blog.jquery.com/2011/11/03/jquery-1-7-released/#comment-527599)

------
emehrkay
The more I use jQuery, the more of a mess I see that it is. Don't get me
wrong, I'd rather use it than rolling my own cross browser solution, but it is
not the library that Id choose first. I simply do not like the api choices,
the lib works well, the api, as seen in this article, isn't too pretty.

~~~
csomar
Backward compatibility.

Millions (if not hundred of millions) of websites rely on jQuery, switching to
a newer version that breaks old code will wreak havoc and make these sites
unusable.

But this shouldn't stop jQuery from improving. If you have read the article
from the beginning, you'll see how the jQuery team was improving the binding
functionality. It has a cost, certainly. Maybe there should be a jQuery
version with no legacy code.

~~~
davej
Yep, the best advice for a newcomer is to just use `.on()` and familiarise
yourself with that API. You can ignore the other event handler methods because
they're all just shortcuts or legacy methods.

~~~
dmethvin
Exactly. It would simplify the documentation to simply deprecate everything
but .on() but would that justify breaking all the existing code out there? Not
to me. The old APIs need to stay around so that code continues to work.

~~~
cgoddard
Even if they excised the old methods from the code, hopefully no one is
linking to jQuery trunk or something as their primary library. The old
versions would still be around. Just some simple work might have to be done to
update a web app to using the latest versions of jQuery.

------
bluesnowmonkey
> _The method attaches the same event handler to every matched element in the
> selection._

Why is that a con for .bind()? This used to be considered a performance
_benefit_ compared to onclick.

~~~
rimantas
I think you misread this. It does not bind the same instance of the handler to
each element. Each element gets its own copy of this handler, hence the waste
of memory.

~~~
dcher
What? No they don't, unless you're making the handler in a loop.

$( "div" ).click( function() {} );

Each div will have the same handler applied, it doesn't make a new one for
every div.

~~~
stephenr
You're confusing the callback with the actual event listener.

------
easymode
I experienced this dilemma first hand. Thank you very much for explaining it
clearly.

------
ars
That html snippet at the top is quite strange - it's not legal to put an H3 or
a P in an A.

~~~
Chris_Newton
It's legal in HTML5:

[http://dev.w3.org/html5/spec-author-view/the-a-
element.html#...](http://dev.w3.org/html5/spec-author-view/the-a-
element.html#the-a-element)

------
wnoveno
on a slightly less relevant note. is live() pronounced as live as in live wire
or live as in die/live? we had a little debate going here on our office about
this and we need closure dammit!

~~~
ars
I'm pretty sure it's live like live wire. The event is alive.

~~~
rudd
On the other hand, the opposite of live() is die(). Odd.

~~~
ars
Here you go: <http://www.mrspeaker.net/2009/11/12/how-to-pronounce-live/>

A definitive answer to this very important question.

------
baddox
I see "it's" used as the possessive pronoun so often and so deliberately by
educated authors that the descriptive linguist in me is starting to think
"its" has been deprecated. Still, the prescriptive linguist in me is repulsed.

------
blueprint
Don't forget to check out livequery.

<http://docs.jquery.com/Plugins/livequery>

"Live Query utilizes the power of jQuery selectors by binding events or firing
callbacks for matched elements auto-magically, even after the page has been
loaded and the DOM updated."

Oh so awesome.

~~~
bretthopper
Why? That plugin was created before jQuery had .live() (which has since been
made useless by the better delegate/on).

The only reason you should use this plugin is if you're stuck with jQuery
<1.3.

~~~
blueprint
Perhaps I'm mistaken about this, especially since this article was my first
time hearing about delegate, but I believe that live and delegate are only
able to be used for existing DOM events like "click", etc., whereas livequery
calls a function on occurrences like elements appearing in the DOM, for which
there is no built-in way to watch with jQuery.

I usually use it to watch when elements appear and then bind handlers to them
inside the callback. Kinda does away with the need for live.

~~~
bretthopper
That's exactly what live/delegate/on does. You can bind events to "future" DOM
elements.

You don't need to watch for the elements though. You just delegate the event
to an element/selector higher in the DOM tree and use event
propagation/bubbling.

I suggest you read up on event delegation.

~~~
jaredsohn
But can you detect when DOM elements are created? (Which is different than
adding a click event to new DOM element.)

I was looking into this issue myself recently and ultimately (through advice
on Stackoverflow) decided to just ignore jQuery and to use DOM mutation
events. I'm still curious if there is a way to do this using jQuery, though.

While working on this I briefly considered livequery due to this StackOverflow
post ([http://stackoverflow.com/questions/4818020/livequery-
perform...](http://stackoverflow.com/questions/4818020/livequery-
performance)), but soon realized that this only intercepts DOM changes made
via jQuery, and won't work with code in the wild (which is what I need since
it is for a Chrome extension.)

~~~
bretthopper
You can use the DOMNodeInserted event. Something like this:

document.addEventListener("DOMNodeInserted", function(event) {
console.log($(event.target).parent()); });

That will log the element that gets inserted into the DOM.

~~~
jaredsohn
That's roughly what I'm doing now (i.e. DOM mutation events). It just isn't
using jQuery.

~~~
bretthopper
Is that a problem? You can use jQuery to wrap the event target like my example
did. Or just do $(document).bind('DOMNOdeInserted', function () {}); Is that
using jQuery enough? I suppose if you knew you were only using jQuery and
wanted to modify the source, you could somehow hook into every function that
modifies the DOM and go from there (which is what you just described with
livequery).

Not really sure why your requirement is it needs to "use" jQuery though.

~~~
jaredsohn
Not really; my code is working fine as is. I think the "problems" were 1) I
was curious if there was a way to do it via jQuery instead of DOM mutation
methods (looks like no) and 2) the documentation for these jQuery methods
doesn't specifically mention that this case isn't covered and that the
developer should look at DOM events, although that is just perhaps assumed to
be default behavior when working with jQuery.

I'm writing to the people who maintain the jQuery documentation now...

