Hacker News Reader

Comment by alxndr | Hacker News Reader

> jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of users out there who are on modern browsers instead of a mediocre experience for 100% of them?

Ignoring the Webkit example and focusing on IE, isn't that what jQuery 2 is for?

View on HN

Nope. jQuery 2 just removed code for IE 6/7/8. Nothing was added. Code sized reduced, but almost the same performance. My benchmark shows only 10-15% improvement. That's nothing compared to using the DOM API straight up.

Care to substantiate your benchmark where you compare jQ1, jQ2, and the native DOM API?

Here is the mentioned pull request: https://github.com/jashkenas/backbone/pull/2959

Here is his benchmark: http://jsperf.com/backbone-patch-22be8f9/2

It only compares jQuery 1 and the DOM API, no jQuery 2.

    TestBaseView: DOM API
    TestPaulView: Reduced jQuery usage
    TestView: jQuery

Yep that's it. You can replicate this benchmark and replace jq1 with jq2 to see how much faster it gets. You'll be disappointed.

Hmm, I'm wary of a test that involves another framework to test the underlying jQ v. Native DOM performance difference. I'd be much more comfortable eliminating Backbone from the equation.

Also, this is just one test - wyuenho's claim was for jQ vs. the DOM in general, which is a much broader claim than an unknown subset of functionality.

I don't doubt that native DOM methods are faster than jQ, but I like claims to be backed up by evidence.

The evidence is in the form of an experiment repeatable from your browser's dev console. Play with it.

If you hand me some code to run, I'll run it. Otherwise my test risks not being the same one that you used to make the claim.

The onus is on the person making the claim, not the person trying to verify it.

Isn't the code to run here[1]?

[1]: http://jsperf.com/backbone-patch-22be8f9/2

See my previous comment[0]. That perf test is testing Backbone's use of jQ vs. native DOM, not jQ v. DOM in isolation. I don't trust that there aren't side effects and interactions in the test.

[0]: https://news.ycombinator.com/item?id=7155710

Reply on news.ycombinator.com