Drawbacks to always using live() instead of bind() for unique dom elements ?

Question

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.

Answer 1

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/

Answer 2

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.

Answer 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.