http://www.cinsoft.net/mylib.html

Both are experts on JavaScript and while David Mark is controversial, Peter Michaux is not. If he is hating jQuery (and he is not the only one, about 75% of that JSMentors list considers jQuery bad), that must be for a reason. Google for "browser sniffing" vs. "feature detection" to make your own opinion.

http://groups.google.com/group/comp.lang.javascript/msg/37cb...;

If you want to see other criticisms for them, search c.l.j archives on Google Groups (I admit it's not easy ever since Google ruined Groups search).

The thing with jQuery is it's not as simple as "I hate jQuery." The basic idea behind jQuery (selectors) is a great way of doing stream processing over the DOM. This is a really convenient way of working with existing HTML pages.

The main reason David Mark dislikes jQuery is that (at least at the time) it was poorly implemented. Before I ever came across his posts, I tried reading jQuery code and thought it was very hard to understand, but bought the conventional wisdom excuse that JavaScript programming was special because of cross-browser hacks and people like Resig were "ninjas." Then I came across Michaux's code, read Mark's posts, and realized that the "JavaScript ninjas" were really just writing bad code.

But that doesn't change the fact that jQuery is very convenient to use for manipulating existing HTML pages. But there's another problem there - jQuery does stream processing eagerly at run-time. This is extremely inefficient, and there's no reason to do it for pages where you have control over HTML.

A lot of work has gone into caching in jQuery to avoid duplicated selector search, by far the biggest overhead (conceptually, you're doing an exhaustive search over the entire DOM every time you execute a selector).

But that still doesn't address the fact that the results of the selectors are produced eagerly, and processed by every operator eagerly. There are two optimizations that can be made here: map fusion and lazy evaluation. The latter is possible, but would require rewriting jQuery and changing its interface. The former is impossible without a preprocessing step.

But like I said, there's really no reason to even bother using jQuery with pages where you have control over your HTML and can put the objects you need into arrays and hash tables to be there when you need them. That, and the move of web applications to canvas (at this point I'm convinced it's inevitable) make jQuery irrelevant at this point in time IMO.