Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()
elijahmanor.com
elijahmanor.com
In addition, when you see something like:
$('.table a').click(function() { ... } )
http://blog.jquery.com/2011/11/03/jquery-1-7-released/#comme...
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.
$(selector').addEvent('click:relay(selector)', fn)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.
One way I solve the issue around overloaded apis is by not using them. I just pretend .click() and friends just don't exist.
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.
That is awesome, thanks for pointing it out!
Which library/libraries would you choose first, over jQuery?
Thanks.
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.
> 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.
> Most of your argument boils down to "jQuery makes it easy for shit developers to write shit code, therefore you shouldn't use it".
Shit developers will write shit code regardless of a library, just as good developers will write good code. The problem is that jQuery provides an abstraction to what's actually happening, and how the DOM treats events in the browser. The present status-quo of jQuery code boils down to abuse of innerHTML="foo", and binding events onto individual elements rather than bubbling up to a parent listener.
As I said, the culture around jQuery propagates the web with sub-standard code simply because it attracts cut+paste+tweak developers who don't really understand jQuery, never-mind what's going on behind the curtain, or how to use events in such a way that can lead to long-term maintainability. It discourages best practices because it's really good at hiding reality from developers.
Even if you're a good developer, why should you use jQuery? You aren't necessarily getting anything more done than usual if you know what you're doing and using a micro-framework under 10kb, or expand your framework with one of the modular fameworks that let you do so. Don't like Sizzle selector engine? Use something else.
> Compared to what? What parts are slow? Keep in mind it needs to support legacy browsers like IE6 before you answer those questions.
Compared to plain old JavaScript. Almost all of it is slower, modifying the DOM, binding events, AJAX has been known to expose memory leaks (an on-going problem in other places as well), jsperf is full of people who set up test cases to see the difference between jQuery and vanilla JS: http://jsperf.com/browse
Two contrived examples, feel free to explore some more...
1. http://jsperf.com/queryselector-vs-getelementbyid-perf
2. http://jsperf.com/modern-js-vs-jquery-append
Legacy support should not be a unilateral feature that every browser has to fell the pain of, it goes against the grain of progressive enhancement practices. I don't really buy into the whole "we have to support IE6" any more that it's now under 1.5% everywhere that's in my market. However, legacy support can easily be provided through polyfills that append the DOM methods, and standard JS object prototypes, sometimes these are called shims as well, it supplements a broken legacy browser-native API with something that matches modern implementations, or in some cases, normalizes spec implementation discrepancies. This means I don't have to check for activeX object every time I goto make an AJAX request, or other costly things.
This is a trap that a lot of people fall into when benchmarking with jsperf. It is perfectly valid to say that the bare DOM functions are TEN times faster than jQuery at this particular task. But even the "slow" jQuery case runs more than 16,000 times in a second on Chrome. That ain't slow; you are unlikely to be injecting more than a dozen or so boxes a second so this isn't going to be your bottleneck.
These kind of benchmarks don't represent reality when you scale to an app where the inability to inject more than 16,000 boxes into a page per second might even conceivably be a bottleneck. It would be much more common, for example, to be building HTML templates via Mustache and injecting them all at once. Show me the comparison of doing that whole thing with DOM functions. :)
It is always better to start with some real code that is not performing well and find its bottlenecks. With that in mind I agree that using .live() with complex selectors or high-frequency events like mousemove is bad design. Preventing that sort of unknowing abuse is exactly why we deprecated .live() in 1.7. But I disagree with the generality that "jQuery is slow" simply because it doesn't compare well on some isolated jsperf tests, or because it provides powerful abstractions that can be abused.
That being said, I have run into situations where I absolutely do need performance. I've tried to load 10k records into the popular http://www.datatables.net/ plugin (I have a legitimate reason, I swear), and it tends to crash my browser simply because the author uses a lot of these per-element-bindings and innerHTML calls, but I was about to use jqGrid http://www.trirand.com/jqgridwiki/doku.php which managed to write the jQuery code in a way that avoids those bottlenecks and is able to deal with 10k records without crashing. So yes, you can use jQuery and write better performance than other cases out there, but that's not what I'm trying to get at.
I'm saying jQuery encourages a lot of bad things that competent programmers can avoid without using this specific library for everything, and novice programmers can gain a better understanding of the browser through not using "hocus pocus" to make sites.
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.
Someone's working on a DOM polyfill at the moment, it's unstable beta but looks promising: https://github.com/Raynos/DOM-shim
Why is that a con for .bind()? This used to be considered a performance benefit compared to onclick.
$( "div" ).click( function() {} );
Each div will have the same handler applied, it doesn't make a new one for every div.
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).
http://dev.w3.org/html5/spec-author-view/the-a-element.html#...
A definitive answer to this very important question.
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.
The only reason you should use this plugin is if you're stuck with jQuery <1.3.
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.
You don't need to watch for the elements though. You just delegate the event to an element/selector higher in the DOM tree and use event propagation/bubbling.
I suggest you read up on event delegation.
I was looking into this issue myself recently and ultimately (through advice on Stackoverflow) decided to just ignore jQuery and to use DOM mutation events. I'm still curious if there is a way to do this using jQuery, though.
While working on this I briefly considered livequery due to this StackOverflow post (http://stackoverflow.com/questions/4818020/livequery-perform...), but soon realized that this only intercepts DOM changes made via jQuery, and won't work with code in the wild (which is what I need since it is for a Chrome extension.)
document.addEventListener("DOMNodeInserted", function(event) { console.log($(event.target).parent()); });
That will log the element that gets inserted into the DOM.
Not really sure why your requirement is it needs to "use" jQuery though.
I'm writing to the people who maintain the jQuery documentation now...