What is the difference between the bind and live methods in jQuery?

B

10

65

I'm curious to know the differences between the bind and live functions.

To me they seem to be almost identical.

I read the benefits of live/bind methods, but it didn't tell me about the differences...

Thanks!

Brashear answered 1/6, 2009 at 22:5 Comment(2)

In addition to the answer below, readers might want to have a look at this unbelievably good article explaining the difference between bind, live and delegate. – Evaluate 7/12, 2011 at 0:41

Update: Since jquery 1.7 - ´live()´ is deprecated in favor for on(). – Artilleryman 19/12, 2012 at 9:47

T

77

.bind() attacheds events to elements that exist or match the selector at the time the call is made. Any elements created afterwards or that match going forward because the class was changed, will not fire the bound event.

.live() works for existing and future matching elements. Before jQuery 1.4 this was limited to the following events: click, dblclick mousedown, mouseup, mousemove, mouseover, mouseout, keydown, keypress, keyup

Teen answered 1/6, 2009 at 22:9 Comment(3)

For anyone reading this now, .live() is no longer limited to the events listed above. The .live() event now has support in jQuery 1.4 for all events, including custom events. – Mantinea 28/8, 2010 at 17:25

this answer does not really answer the question, see below answer by nickf for the requested explanation – Ism 12/6, 2011 at 15:26

Bind is just a poor and limited live… why on earth does it still exists ? – Pustule 13/7, 2012 at 10:43

R

89

In short: .bind() will only apply to the items you currently have selected in your jQuery object. .live() will apply to all current matching elements, as well as any you might add in the future.

The underlying difference between them is that live() makes use of event bubbling. That is, when you click on a button, that button might exist in a <p>, in a <div>, in a <body> element; so in effect, you're actually clicking on all of those elements at the same time.

live() works by attaching your event handler to the document, not to the element. When you click on that button, as illustrated before, the document receives the same click event. It then looks back up the line of elements targeted by the event and checks to see if any of them match your query.

The outcome of this is twofold: firstly, it means that you don't have to continue reapplying events to new elements, since they'll be implicitly added when the event happens. However, more importantly (depending on your situation), it means that your code is much much lighter! If you have 50 <img> tags on the page and you run this code:

$('img').click(function() { /* doSomething */ });

...then that function is copied into each of those elements. However, if you had this code:

$('img').live('click', function() { /* doSomething */ });

...then that function is stored only in one place (on the document), and is applied to whatever matches your query at event time.

Because of this bubbling behaviour though, not all events can be handled this way. As Ichiban noted, these supported events are click, dblclick mousedown, mouseup, mousemove, mouseover, mouseout, keydown, keypress, keyup.

Reconnoitre answered 2/6, 2009 at 0:25 Comment(9)

Thanks for the explanation of how this works. The jQuery documentation doesn't explain any of this, which seems important for using it. – Maidamaidan 23/3, 2010 at 18:46

@meagar: "Because of this bubbling behaviour though, not all events can be handled this way. As Ichiban noted, these supported events are click, dblclick mousedown, mouseup, mousemove, mouseover, mouseout, keydown, keypress, keyup." So now that it works for all events in later versions of jQuery, is it still working by being attached to the body and triggered when the body finally receives the bubbled event, or did that change? – Ism 12/6, 2011 at 15:25

Great answer! Really helps to understand what goes on in the code. Was actually looking for this. Big +1 from me! – Lanilaniard 22/3, 2012 at 8:57

I'm not sure I agree with the rationale of why live() is a 'lighter' solution. Yes, in the example, the click() handler will be copied 50 times. But that happens (and the copies are stored) behind the scenes, and it only happens once. Additionally the execution of the handler function is simpler in that case, since there's no need to inspect where the event came from and match selectors before invoking the actual event handler. So live() is lighter in terms of space and setup time, but slightly heavier in terms of runtime processing. – Disassembly 20/2, 2013 at 23:21

Edit: I'm not even sure it would be copied 50 times; I think what you probably end up with is 50 references to a single copy, with jQuery making clever use of apply() and/or call() to set the value of this appropriately each time the event handler is triggered. That's how I'd do it anyways. I suppose checking the source code is the only way to know for sure though. – Disassembly 20/2, 2013 at 23:37

aroth - you're completely correct. I was young and stupid when I wrote this answer, but never got around to correcting it. – Reconnoitre 22/2, 2013 at 10:49

@Reconnoitre I can learn a lot from your answer , thanks, But I have a question for you ,what you mean is event bubble or event capture ? becuase event bubble goes up but capture goes deep , thanks. – Recession 2/3, 2013 at 13:17

What I can contribute this answer is the live() method can only be used on selectors, and can’t be used on derived wrapped sets. – Recession 2/3, 2013 at 13:35

and more is seems live triggers the event by the script.not use the event handler. – Recession 2/3, 2013 at 13:40

T

77

.bind() attacheds events to elements that exist or match the selector at the time the call is made. Any elements created afterwards or that match going forward because the class was changed, will not fire the bound event.

.live() works for existing and future matching elements. Before jQuery 1.4 this was limited to the following events: click, dblclick mousedown, mouseup, mousemove, mouseover, mouseout, keydown, keypress, keyup

Teen answered 1/6, 2009 at 22:9 Comment(3)

For anyone reading this now, .live() is no longer limited to the events listed above. The .live() event now has support in jQuery 1.4 for all events, including custom events. – Mantinea 28/8, 2010 at 17:25

this answer does not really answer the question, see below answer by nickf for the requested explanation – Ism 12/6, 2011 at 15:26

Bind is just a poor and limited live… why on earth does it still exists ? – Pustule 13/7, 2012 at 10:43

B

5

Bind will bind events to the specified pattern, for all matches in the current DOM at the time you call it. Live will bind events to the specified pattern for the current DOM and to future matches in the DOM, even if it changes.

For example, if you bind $("div").bind("hover", ...) it will apply to all "div"s in the DOM at the time. If you then manipulate the DOM and add an extra "div", it won't have that hover event bound. Using live instead of bind would dispatch the event to the new div as well.

Breed answered 1/6, 2009 at 22:12 Comment(0)

O

5

Nice read on this: http://www.alfajango.com/blog/the-difference-between-jquerys-bind-live-and-delegate/

Is nowadays (since jQuery 1.7) deprecated using the .on() function - http://api.jquery.com/on/

Oriental answered 13/1, 2012 at 13:18 Comment(0)

I

4

imagine this scenario:

i have several <img> elements.
- $('img').bind('click', function(){...});
- add some extra images (using get(), or html(), anything)
- the new images don't have any binding!!

of course, since the new images didn't exist when you did the $('img')... at step 2, it didn't bind the event handler to them.

now, if you do this:

i have several <img> elements.
- $('img').live('click', function(){...});
- add some extra images (using get(), or html(), anything)
- the new images do have the binding!!

magic? just a little. in fact jQuery binds a generic event handler to another element higher in the DOM tree (body? document? no idea) and lets the event bubble up. when it gets to the generic handler, it checks if it matches your live() events and if so, they're fired, no matter if the element was created before or after the live() call.

Intense answered 1/6, 2009 at 22:13 Comment(0)

D

3

In adition to what they said, I think it's best to try to stick to bind when/where you can and use live only when you must.

Dagostino answered 1/6, 2009 at 22:17 Comment(4)

You're right. .live is a must for ajax events, though, right? – Brashear 1/6, 2009 at 22:25

Why do you say that? I've found that live simplifies the code. I'm pretty picky about performance, and it seems fine to me. What's the downside? – Philosophy 2/6, 2009 at 0:29

Well, first of all because not all events are available with live(). Secondly, because I think they are harder to manage (no stopPropagation and stopImmediatePropagation), and third because live() surely generates more overhead than bind() (as it looks for changes in the DOM). Maybe not a killer difference, but still. That's why I tend to stick to bind() where possible. – Dagostino 2/6, 2009 at 8:44

live() doesn't look for DOM changes, it maintains a list of target selectors and checks them at event time (the events fire on document). There is some overhead, but it's very minimal. The real danger is that some uses of live can cause garbage collection to fail. – Linette 9/10, 2009 at 15:40

T

1

All these jQuery methods are used for attaching events to selectors or elements. But they all are different from each other.

.bind(): This is the easiest and quick method to bind events. But the issue with bind() is that it doesn’t work for elements added dynamically that matches the same selector. bind() only attach events to the current elements not future element. Above that it also has performance issues when dealing with a large selection.

.live(): This method overcomes the disadvantage of bind(). It works for dynamically added elements or future elements. Because of its poor performance on large pages, this method is deprecated as of jQuery 1.7 and you should stop using it. Chaining is not properly supported using this method.

Find out more here

Teasel answered 12/2, 2014 at 14:9 Comment(0)

S

0

I wanted to add to this after having to debug a bit due to my own silliness. I applied .live() to a class of button on my page, assuming that it would just render out the correct ID I was trying to pass on the query string and do what I wanted to do with the ajax call. My app has dynamically added buttons associated with an inventory item. For instance, drill down categories to the 'COKE' button to add a coke to your order. Drill down from the top again, and add 'BUDLITE' - each time I wanted those items to be entered into a table via an AJAX call.

However, since I bound .live() to the entire class of buttons, it would remember each ajax call I had made and re-fire it for each subsequent button! It was a little tricky because I wasn't exactly clear on the difference between bind and live (and the answer above is crystal about it), so I figured I'd put this here just in case somebody was doing a search on this stuff.

Sadden answered 10/7, 2009 at 4:16 Comment(0)

R

0

There is a way to get the live effect but its kind of nasty.

$(this).unbind('mouseout').bind('mouseout',function(){ });

this will clear the previous and reset the new. It has seemed to work fine for me over time.

Reedy answered 9/10, 2009 at 15:34 Comment(1)

Or you can use proper event delegation, bind the events to document, and check the event's target. – Linette 9/10, 2009 at 15:40

G

0

Difference between live and livequery is discussed here .

Gid answered 14/10, 2009 at 19:55 Comment(0)

Recommended topics

Hot tags