Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()

http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html

by elijahmanor • 14 years ago

325 60 14 years ago

emehrkay4• 14 years ago

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• 14 years ago

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• 14 years ago

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.

emehrkay4• 14 years ago

The overall api is strange. The each loops are backwards from the spec (key, value) instead of (value, key) and there are instances where it is key, value in jquery, there are instances where method names just don't make sense (I'd expect something like size to be dimensions etc), getters and setters as the same method, way too much argument overloading, inconsistent approach (selector.action, but wrap is the opposite of how the rest of the lib works). There is no kind of inheritance for their plugin architecture.

These are just things off the top of my head. I feel like jQuery is the same as PHP when it comes to api, and I make a living doing PHP.

prolepunk• 14 years ago

Yet it breaks hilariously when you try to move from 1.3.2 to 1.4.4. I still have ONE script for which I have to deal with jquery-1.3.2.

jonknee• 14 years ago

> Maybe there should be a jQuery version with no legacy code.

They're deprecating stuff, so it's just a matter of time. I think that's the sensible way to do things.

http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/

They're also taking steps to be able and use Google Closure Compiler's advanced optimizations, which would let you build jQuery against your code and trim out everything that's not used. Pretty handy.

jacobr2• 14 years ago

A 2.0 release would be a reasonable point to potentially break legacy code.

v33ra• 14 years ago

Jquip is trying to make jquery less messy by splitting into separate modules.

fooyc• 14 years ago

But it failed to use a proper module format (e.g. CommonJS / AMD)

jsdalton2• 14 years ago

> ...but it is not the library that Id choose first.

Which library/libraries would you choose first, over jQuery?

maratd• 14 years ago

MooTools. Dojo. The herd has been thinned a bit over the last few years.

jacobr2• 14 years ago

I would use Ender and pull together various micro-libraries/modules.

http://ender.no.de

oinksoft• 14 years ago

For a complete one-off, plain JavaScript and DOM. For a small, simple project, MooTools. For a large project, Closure Tools. jQuery's not a good choice for anything I work on, and its "God Object" API makes for repugnant code.

funkah• 14 years ago

I've been using Prototype for years and am now using jQuery more, and I have to agree. The knock against Prototype was that it modifies built-in classes, but I seriously doubt how much that actually matters, and as a programming library it makes much more sense to work with, I think. jQuery doesn't even offer very useful things like list comprehensions! You have to use underscore to get those.

emehrkay4• 14 years ago

There is a grep method that does some stuff:

http://api.jquery.com/jQuery.grep/

tikhonj• 14 years ago

Actually, splitting out logical code from DOM manipulation code makes plenty of sense. Just because I'm using one does not mean I want the other and both stand on their own fairly well. This is even more important now that JavaScript is popular on the server--I can use Underscore there as well.

bdg5• 14 years ago

> the more of a mess I see that it is.

I started a joke project to mock the total mess that jQuery has become, http://cowbelljs.com/ . The performance hit from using jQuery is awful these days, it's become a monolithic framework aimed towards support for a hodge-podge of things rather than using best practices.

A simple line of code such as this might be readable:

$(".foo input[type=checkbox]:checked").live(function(e){fizzbuzz(e)})

But, the costs of that? You've just killed performance, your page is probably going to have laggy response and all kinds of event listener issues crop up as you keep working, leading to you using .die, .stopeventpropegation, .stopeventbubbeling, and return false all over the place in a futile attempt to manage your events.

jQuery does a great job of letting you write less code, it also does a good job of abstracting away tasks and making things look like "magic", but it also really makes it easy to shoot yourself in the foot, with a tommy gun.

jQuery creates a lot of undesirable effects, as far as I'm concerned:

- People don't understand what their code does.

- jQuery API is a mess, and version upgrades are hard

- Best practices for a given task are not focused on, rather, "every practice" is accepted, and whatever blog post the JS novice read at the time becomes the method they write their code with (as a result, we almost never see .delegate() in use)

- The library is huge. Yes, they brag about it being only 31kb minified, but that's huge!

- jQuery code is slow.

- Nobody understands how the DOM API works any more, and because sizzle makes it easy to select complex things the authors don't even bother writing semantic HTML, so we start to see <td id="Row2Cell2"> kind of things.

- We have landed in a mess where ambitious people tightly couple their projects with an unstable API and practices that create sluggish pages.

Sure, you can use jQuery correctly, but I'd rather use a micro-framework that complements JavaScript rather than attempt to replace it with tightly-coupled abstraction layers and memory hogging through event listeners and timers all over the place. The culture around it makes me really sad.

driverdan• 14 years ago

Most of your argument boils down to "jQuery makes it easy for shit developers to write shit code, therefore you shouldn't use it". No response necessary.

> jQuery code is slow

Compared to what? What parts are slow? Keep in mind it needs to support legacy browsers like IE6 before you answer those questions.

strickjb92• 14 years ago

I see jQuery misused every day, I'm pretty sure I was one of those terrible people a couple years ago. Since then I hardly use jQuery anymore except for delegate() and that's only because I haven't explored other libraries to replace it.

jQuery, if used responsibly, is still a good library.

Unfortunately, you are correct that the culture around it stinks. jQuery is the tool of choice for bad developers to write bad code.

MatthewPhillips• 14 years ago

I don't use JQuery anymore at all. I just use element.addEventListener with a polyfill for attachEvent if I need to hit old IE.

bdg5• 14 years ago

Poly-fill is the future.

Someone's working on a DOM polyfill at the moment, it's unstable beta but looks promising: https://github.com/Raynos/DOM-shim

jd• 14 years ago

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.

strickjb92• 14 years ago

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

bdg5• 14 years ago

You should take a look into event delegation with bubbling, event listeners should be minimal.

http://javascript.info/tutorial/bubbling-and-capturing

http://javascript.info/tutorial/event-delegation

bluesnowmonkey• 14 years ago

> 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• 14 years ago

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• 14 years ago

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.

spohlenz• 14 years ago

Compared to onclick, it's certainly a performance benefit.

However the difference here is in looping over every matched element to add the handler (bind) versus adding the handler to a single element further up the DOM tree (delegate).

baddox• 14 years ago

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.

easymode• 14 years ago

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

blueprint2• 14 years ago

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.

bretthopper4• 14 years ago

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.

blueprint2• 14 years ago

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.

wnoveno• 14 years ago

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!

howardr• 14 years ago

Like live wire

ars3• 14 years ago

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

rudd• 14 years ago

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

ars3• 14 years ago

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• 14 years ago

It's legal in HTML5:

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

Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()

Related Stories