What's wrong with the jQuery live method?

Question

The live() method was deprecated in jQuery 1.7. The jQuery docs now recommend

Use .on() to attach event handlers. Users of older versions of jQuery should use .delegate() in preference to .live().

I understand how on and delegate work, but I don't understand why they are better. live() is simpler and easier to use.

Is there a reason why live was deprecated? How are the other methods better? Will anything bad happen if I continue to use live?

Other than your code breaking when they stop supporting it? Not much... especially if you use a local copy of jQuery... — Lix, Jun 20 '12 at 08:47
The answers below are good, but there's one practical aspect to deprecation: the toolkit developers no longer need to support `live`. Since they've added `on` and think that it's a good solution, they no longer want to have to support and maintain `live`, so they have deprecated it, regardless of whether it is bad or good. In this case, there are some reasons to avoid `live`, but in the general case, if a method is added to a toolkit for *any* reason, the developers may choose to deprecate methods that perform similar actions for ease of maintenance. — Dancrumb, Jun 20 '12 at 13:31

score 33 · Accepted Answer · edited Oct 29 '13 at 00:15

See some of the explanations here:

~~http://www.ultimatewebtips.com/why-jquery-live-is-a-bad-option-to-use/~~ (Site appears to be down)

Quote:

You can’t use .live() for reusable widgets.
.stopPropagation() doesn’t work with live.
.live() is slower.
.live() is not chainable.

Further beauty of .on() is that it streamlines all events quite well: http://api.jquery.com/on/

D'uh you know about the api link and see how .on() works :)

Quote:

The .on() method attaches event handlers to the currently selected set of elements in the jQuery object. As of jQuery 1.7, the .on() method provides all functionality required for attaching event handlers. For help in converting from older jQuery event methods, see .bind(), .delegate(), and .live(). To remove events bound with .on(), see .off(). To attach an event that runs only once and then removes itself, see .one()

Notwithstanding the fact that `.live()` was removed in jQuery 1.9, points 1, 2 and 3 need to be heavily qualified, and point 4 is just plain wrong. — Beetroot-Beetroot, Mar 27 '13 at 02:52

Mattias Buelens · Answer 2 · 2012-06-20T22:48:08.963

live() is inefficient for two reasons:

In the construct $('selector').live(), jQuery first has to select all elements. However, when calling live(), it only needs the selector of the jQuery object (stored in .selector) and doesn't actually use any of the selected elements. Therefore, it is somewhat wasteful to first select all matching elements and then not using them. on() and delegate() take the target selector as a parameter which means that no target elements are selected beforehand and the testing occurs only when the event is triggered.
live() by default is bound at the document level, thus all events need to bubble up through the whole DOM. You can narrow it down by specifying a context with $(selector, context).live(), but it's better to use on() or delegate() for this.

When writing new code, it is strongly recommended to use the latest and greatest on() instead of delegate() and the deprecated live(). However, I don't think support for live() will be dropped anytime soon (if ever), as so many scripts rely on it. Also, there's no real disadvantage of using live() over on(), as in the jQuery source itself live() is defined as:

live: function( types, data, fn ) {
    jQuery( this.context ).on( types, this.selector, data, fn );
    return this;
}

`$(selector, context)` doesn't change `.context`, so it would still be `document`. You have to pass dom element like `$($("body")[0]).find("span")` to change `.context` to something else — Esailija, Jul 16 '12 at 19:48

score 4 · Answer 3 · answered Jun 20 '12 at 08:59

There are two main issues with the live method:

It attaches all event handlers at the document level, so any event that bubbles up to the document has to be matched against the event types and selectors for all live events. If you have a lot of events, the page will be sluggish. You should use delegate or on to limit the scope of where you check the events.
The usage of the method is not typical for how selectors is used with other methods in the library. You can only use it on jQuery objects that are created using a selector. The delegate and on methods makes this natural as you supply the selector to the method.

Robin Castlin · Answer 4 · 2012-06-20T08:52:50.213

1

I'm rather sure this is due to the nature of .live(). It's convinient and all, but it's a bad practice to use since it forces your browser to in most cases search for more events then required.

Instead of by default searching the entire documents for a certain event, it's more data efficient to search a specific container.

live() indeed was convenient to use, and most os uf never noticed any flaws with using it. It was basicly an improved bind() in my eyes.

But in many times we have to adapt and be more clear to our code on what needs to be executed.

It's like asking yourself why you have to import stuff, and why not everything is imported at the initiation.

edited Jun 20 '12 at 08:52

answered Jun 20 '12 at 08:47

Robin Castlin

10,956
1
28
44

I thought you could limit the search by the selection string, i.e. `"#mydiv .edit"` rather than `".edit"`. – Peter Olson Jun 20 '12 at 08:49
Not really. live() will always check if there's a `.edit` inside a `#mydiv` in the entire document on every event execution. Not find an existing `#mydiv` and check its children. – Robin Castlin Jun 20 '12 at 08:50

score 1 · Answer 5 · answered Jun 20 '12 at 08:49

live() attaches the handlers to the document, which basically results in intercepting all events of the given kind, incurring the cost for a search for elements matching the selector. with delegate() and on(), you are recommended to attach closer to the expected targets (in their direct parent, if possible), thus narrowing the number of handled events, and respectively searches for matching targets.

score 1 · Answer 6 · edited Aug 18 '17 at 04:45

1

Here's a detailed article by Paul Irish about live() performance and limits.

If you continue using live, soon or later your code could not work anymore if you upgrade the jQuery library on your projects.

edited Aug 18 '17 at 04:45

Tot Zam

8,406
10
51
76

answered Jun 20 '12 at 08:50

Fabrizio Calderan

120,726
26
164
177

score 0 · Answer 7 · answered Jun 20 '12 at 08:51

$('some selector').live(' ... ', handler)

is the same as

$(document).on(' ... ', 'some selector', handler)

So when you use live you actually assign all your handlers to the root of your DOM tree. There are two disadvantages for that:

Attaching handlers to DOM root increases the path the event has to traverse while buubling up. That would impact performance in a bad way.
There's an increased risk that some other handler with return false at the end will prevent live handler from firing.

What's wrong with the jQuery live method?

7 Answers7

Linked