3 ms·
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
by bdg 15y ago
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/ 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 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.