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.
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...
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.
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.
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:
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.
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.
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.
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).
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!
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.
"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."
[+] [-] jd|14 years ago|reply
In addition, when you see something like:
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.[+] [-] strickjb9|14 years ago|reply
http://blog.jquery.com/2011/11/03/jquery-1-7-released/#comme...
[+] [-] bdg|14 years ago|reply
http://javascript.info/tutorial/bubbling-and-capturing
http://javascript.info/tutorial/event-delegation
[+] [-] emehrkay|14 years ago|reply
[+] [-] csomar|14 years ago|reply
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.
[+] [-] MatthewPhillips|14 years ago|reply
[+] [-] jsdalton|14 years ago|reply
Which library/libraries would you choose first, over jQuery?
[+] [-] bdg|14 years ago|reply
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.
[+] [-] v33ra|14 years ago|reply
[+] [-] funkah|14 years ago|reply
[+] [-] bluesnowmonkey|14 years ago|reply
Why is that a con for .bind()? This used to be considered a performance benefit compared to onclick.
[+] [-] rimantas|14 years ago|reply
[+] [-] spohlenz|14 years ago|reply
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).
[+] [-] easymode|14 years ago|reply
[+] [-] ars|14 years ago|reply
[+] [-] Chris_Newton|14 years ago|reply
http://dev.w3.org/html5/spec-author-view/the-a-element.html#...
[+] [-] wnoveno|14 years ago|reply
[+] [-] ars|14 years ago|reply
[+] [-] howardr|14 years ago|reply
[+] [-] baddox|14 years ago|reply
[+] [-] blueprint|14 years ago|reply
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.
[+] [-] bretthopper|14 years ago|reply
The only reason you should use this plugin is if you're stuck with jQuery <1.3.