3

When writing jQuery binding events, I typically use the bind() aliases (click(), submit(), etc).

But, the more I use dynamically generated content, the more I find its ambiguous as to when bind() won't work, and end up debugging for a half hour until I try live() and it works.

Within the parameters of ID-selectors (like '#foo', not .classes or elements ('input')):

Are there any drawbacks to just always using live() instead of bind() for these types of bindings, besides the lack of convenient aliases, since there can only be one DOM element tied to a particular ID?

===========

EDIT: I'm not asking what the difference between bind() and live() are; that's been covered. I'm asking what are the drawbacks of just using live() by default, since the temptation is to do so in instances where you can't mistakenly overselect (ie, when you're using a #uniqueDomElement), and avoid thinking about when bind() is not appropriate.

Yahel
  • 37,023
  • 22
  • 103
  • 153
  • 1
    There are some performance draw backs with using live()... this is helpful http://stackoverflow.com/questions/937039/what-is-the-difference-between-the-bind-and-live-methods-in-jquery/937086#937086 ..read the comments – John Hartsock Oct 20 '10 at 19:57
  • bind is for when the objects exist already, live is to automatically bind to new objects created after the call to live. – Fosco Oct 20 '10 at 19:58
  • @John Hartsock you really should have made that the answer... I was going to answer but then I read the linked comments and it feels pointless now :P. – Domenic Oct 20 '10 at 20:02
  • @Domenic. Basically the question has been answered in a previous question. I simply commented the link to the original question and then voted to close – John Hartsock Oct 20 '10 at 20:05
  • @John Hartsock I don't think it fully answers the question. nickf gets closest to answering what I'm looking for (talking about it binding to the document, and possible performance issues), but just because he addresses it passingly doesn't mean the question has been answered. – Yahel Oct 20 '10 at 20:15
  • @John Hartsock Also, that question doesn't ask what I'm asking. That question showed up when I searched; both the question and the accepted answer are for the difference between the 2 functions, not the advantages of defaulting to use live() when possible. – Yahel Oct 20 '10 at 20:26

3 Answers3

3

The main drawback to .live() is weight (this applies when using a large number of .live() handlers), since it attaches an event handler to document and events by default bubble up there (the entire basis of how it works) that means when the event reaches document a few things have to be checked:

  • Do I have any .live() events for this event type?
  • If I do, does the element the event came from match any selectors for those .live() handlers?

The first is pretty cheap, the second is not. Let's take the most common example, the click event. A click event bubbles, so far so good. Let's say we have one or more .live() event handlers for click registered on document...now we have to loop through all of those handlers and compare their selectors to the element the event came from, the more handlers you have, the more expensive this gets, and happens with every click, that's by far the biggest performance penalty for .live().

There are also other concerns, such as attaching/removing the handlers, but that's management of your handlers...the above performance concerns that apply when you have a large number of handlers are the main issue when comparing it to a direct .bind() call.

Nick Craver
  • 623,446
  • 136
  • 1,297
  • 1,155
0

The problem you have with bind is that you must make the call to bind after the elements appear on the page.. In general people call bind on document ready so that they can attach behavior to elements on the page. If an element is added to the page via javascript after that you will need to then apply the same bind call for the new elements added, which is often cumbersome to do, and thus is why you can use .live instead.

.live uses event delegation which means that instead of having a function handler bound to specific elements on the page, jquery manages all the different live calls such that when you make some kind of action which a live handler exists for, it will check if the element you performed that action on matches the given selector (I believe this is how it works). My guess would be it it adds the event to the document body (for clicks/mouse actions).. I'm not sure of the specifics but I know that ocassionally you can get some weird behavior with live if you use it for everything.. Usually its best to use if you have tons of elements which you will apply some behavior to or if you will be adding those elements dynamically via javascript.

Read the docs for more info: http://api.jquery.com/live/

Matt Wolfe
  • 8,924
  • 8
  • 60
  • 77
0

It's a balancing act. Live() binds the events to the document and searches for the fired event target. The advantage to live (i.e. event delegation, in general) is that you are binding just one event handler for an infinite number of arguments. Bind() attaches the event handler directly to the element itself, so if you have 1,000 rows in a table, and you run $('tr').bind(...), you will be binding a 1,000 event handlers. If you did $('tr').live(...) then you would just be binding one event handler.

You can meet in the middle by using .delegate(), its different than live because you specify the context of the event. Therefore, it won't always fire thus is more efficient. Using the table example, you'd use $('table').delegate('tr', 'click', function() { .... });. You gain the advantages of both bind and live w/ minimal drawbacks: you bind 1 event handler, its future proof (w/i the context of that table only), you don't transverse the entire dom looking for 'tr' elements.

Bind, live and delegate all have their place.

Also, on a side note, delegate is just another way to do $('tr', $('table')[0]).live(), but that looks ugly, hence delegate exists.

John Strickler
  • 25,151
  • 4
  • 52
  • 68
  • IMO delegate is always better than .live for 2 reasons: 1. you can be more specific about where the root note is to use event delegate on, and 2. It doesn't loop uncessarily over all elements that match the selector. What I mean by 2 is that if you call $(".livelink").live(...); JQuery will loop over all elements looking for class .livelink and then do nothing with them because the handler isn't even applied to the link.. At least that's how it used to be, maybe something has changed. – Matt Wolfe Oct 21 '11 at 19:22
  • @Matt Oh god, this post is a year old :) delegate() is definitely superior to live(), when assigning a delegate event handler you want to specify your context as narrowly as possible to reduce the number of elements that need to be checked. The only time I'd use live() is if I'm binding to the document-level. Still... I'd still be hesitant incase live() is deprecated someday. – John Strickler Oct 21 '11 at 19:35