Most 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.
Your post reads as if there's an undertone where you're really defensive of the library. If that's the case, there's no point discussing this further, however, lets go ahead anyway.
> 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...
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.
Actually this test is illustrating a performance problem with the wrong thing, which is what makes it so dangerous. jQuery append is fine. It's actually the $('<div id=box></div>') vs document.createElement('div') that is the real performance killer. Which can be easily resolved by doing $(document.createElement('div'))
I entirely agree with you, I'm not about to say jsperf is able to give an accurate representation of the big picture and show your bottlenecks, however, it does demonstrate that jQuery code is actually much slower. The impact is worse when the most culturally-popular methods in JavaScript: replacing innerHTML inside for-loops, and attaching events directly to many elements.
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 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.