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.
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.