7 ms·
Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()
- emehrkay 15y agoThe 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 15y agoBackward 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 15y agoYep, 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.
- dmethvin 15y agoExactly. It would simplify the documentation to simply deprecate everything but .on() but would that justify breaking all the existing code out there? Not to me. The old APIs need to stay around so that code continues to work.
- cgoddard 15y agoThey could deprecate the old methods and still keep them around as long as makes sense. There's no rule that deprecated methods have to be gotten rid of during the next major revision or anything.
- cgoddard 15y agoEven if they excised the old methods from the code, hopefully no one is linking to jQuery trunk or something as their primary library. The old versions would still be around. Just some simple work might have to be done to update a web app to using the latest versions of jQuery.
- emehrkay 15y agoI like MooTools. When they added event delegation to their library, they simply modified the existing addEvent method to parse the event name instead of adding new method after new method -- seems like a more thought out approach. $(selector').addEvent('click:relay(selector)', fn)
- emehrkay 15y agoThe 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.
- mark_story 15y agojQuery.map() jQuery.each() having their arguments has caused me more than a few WAT moments. One way I solve the issue around overloaded apis is by not using them. I just pretend .click() and friends just don't exist.
- prolepunk 15y agoYet 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 15y 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/ 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.
- nfriedly 15y ago> They're also taking steps to be able and use Google Closure Compiler's advanced optimizations... That is awesome, thanks for pointing it out!
- jacobr 15y agoA 2.0 release would be a reasonable point to potentially break legacy code.
- v33ra 15y agoJquip is trying to make jquery less messy by splitting into separate modules.
- fooyc 15y agoBut it failed to use a proper module format (e.g. CommonJS / AMD)
- jsdalton 15y ago> ...but it is not the library that Id choose first. Which library/libraries would you choose first, over jQuery?
- maratd 15y agoMooTools. Dojo. The herd has been thinned a bit over the last few years.
- jacobr 15y agoI would use Ender and pull together various micro-libraries/modules. http://ender.no.de http://ender.no.de
- jsdalton 15y agoThat is very interesting. It looks like they even have a "starter pack" that approximates much of what jQuery does: http://ender.no.de/#jeesh http://ender.no.de/#jeesh Thanks.
- euroclydon 15y agoI winder how it well it works with SVG?
- oinksoft 15y agoFor 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 15y agoI'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.
- emehrkay 15y agoThere is a grep method that does some stuff: http://api.jquery.com/jQuery.grep/ http://api.jquery.com/jQuery.grep/
- tikhonj 15y agoActually, 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.
- bdg 15y 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/ 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 15y agoMost 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.
- MatthewPhillips 15y agoI don't use JQuery anymore at all. I just use element.addEventListener with a polyfill for attachEvent if I need to hit old IE.
- bdg 15y agoPoly-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 https://github.com/Raynos/DOM-shim
- dkubb 15y agoI've often thought that frameworks should be built on top of standardized native apis, poly-filled when necessary. I imagine a time when browser specific hacks will be outside of the frameworks and "pushed down" to something lower level; ultimately shared across several frameworks rather than siloed off like it is now.
- jd 15y agoWhat 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.
- strickjb9 15y agoThis 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/#comment-527599 http://blog.jquery.com/2011/11/03/jquery-1-7-released/#comme...
- bdg 15y agoYou 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/bubbling-and-capturing http://javascript.info/tutorial/event-delegation http://javascript.info/tutorial/event-delegation
- bluesnowmonkey 15y 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 15y agoI 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.
- spohlenz 15y agoCompared 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 15y agoI 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 15y agoI experienced this dilemma first hand. Thank you very much for explaining it clearly.
- blueprint 15y agoDon't forget to check out livequery. http://docs.jquery.com/Plugins/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.
- bretthopper 15y agoWhy? 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.
- blueprint 15y agoPerhaps 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.
- bretthopper 15y agoThat's exactly what live/delegate/on does. You can bind events to "future" DOM elements. 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.
- jaredsohn 15y agoBut can you detect when DOM elements are created? (Which is different than adding a click event to new DOM element.) 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-performance 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.)
- wnoveno 15y agoon 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!
- ars 15y agoThat html snippet at the top is quite strange - it's not legal to put an H3 or a P in an A.
- Chris_Newton 15y agoIt's legal in HTML5: http://dev.w3.org/html5/spec-author-view/the-a-element.html#the-a-element http://dev.w3.org/html5/spec-author-view/the-a-element.html#...