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.<p>In addition, when you see something like:<p><pre><code> $('.table a').click(function() { ... } )
</code></pre>
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.
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.
> <i>The method attaches the same event handler to every matched element in the selection.</i><p>Why is that a con for .bind()? This used to be considered a performance <i>benefit</i> compared to onclick.
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.
Don't forget to check out livequery.<p><a href="http://docs.jquery.com/Plugins/livequery" rel="nofollow">http://docs.jquery.com/Plugins/livequery</a><p>"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."<p>Oh so awesome.