Hacker News Reader

Comment by ivanca | Hacker News Reader

I'm with you in that argument, and here is some code to prove it; a little script that orders all 'divs' based on their size; the jQuery implementation freezes the page for a few seconds while the native one does not (Chrome 26 - i7/2.67GHz - W7 64 bits);

    $("div").sort(function(a, b){
        return $(a).width() * $(a).height() - ($(b).width() * $(b).height())
    });

    [].slice.call(document.getElementsByTagName('div')).sort(function(a, b){
        return a.clientWidth * a.clientHeight - (b.clientWidth * b.clientHeight)
    });

View on HN

Since those two things aren't really the same, I'd say this is a terrible example (a strawman even). If you want the clientWidth, use the clientWidth. jQuery works in tandem with the native DOM, and is not meant to be a wholesale replacement:

    $("div").sort(function(a, b) {
      return a.clientWidth * a.clientHeight - (b.clientWidth * b.clientHeight);
    });

The speed for this is slower, as expected, but comparable to native. http://jsperf.com/d97b341f-cfc1-4057-bdc9-60e80adb5cf6/4

In that context any kind of comparision would be a strawman unless is _your_ way of mixing jQuery with native code; maybe this would become more clear with different examples:

#Ex. 1

    $("div").map(function(){ return $(this).css('background-image'); })

"If you just want the background-image just use the get-computed-style-background-image!"

    [].slice.call(documents.getElementsByTagName('div')).map(function(a){ 
    	return getComputedStyle(a)["background-image"];
    });

#Ex. 2

    $("div").sort(function(a, b){
    	return $(a).find('*').length - $(b).find('*').length;
    });

"If you just want an algorithm that sorts the ones with the biggest amount of children and grandchildren just use an algorithm that sorts the ones with the biggest amount of children using domElement.getElementsByTagName"

    [].slice.call(documents.getElementsByTagName('div')).sort(function(a){ 
    	a.getElementsByTagName('*').length - b.getElementsByTagName('*').length;
    });

>And is not meant to be a wholesale replacement

I never said such thing neither; now that is 100% a straw-man.

Are there speed gains to be had by wrapping the a,b elements in the jQuery example only once instead of twice?

  $("div").sort(function(a, b) {
       var $a = $(a);
       var $b = $(b);
       return $a.width() * $a.height() - ($b.width() * $b.height());
  });

Not really: http://jsperf.com/d97b341f-cfc1-4057-bdc9-60e80adb5cf6

There is however a significant performance improvement to be had by optimising the inner loop, which is what any good programmer would do first here:

http://jsperf.com/d97b341f-cfc1-4057-bdc9-60e80adb5cf6/2

This optimization is actually replacing jQuery in the inner loop with native calls. It was my impression that the OP suggested that this could be performed more efficiently using jQuery.

Written sanely, it's only marginally slower; it's so close that it's inconsequential for 99% of uses.

You still have to download 81Kb of code whereas native is just that, native ;-) It's a trade-off. Depends which browser uses your target/customer.

This isn't entirely fair, as clientWidth isn't really the same thing as $().width().

Can't you just use jQuery.fn.sort if you don't want the chaining and wrapper overheard that the parent mentions? And if you do, won't you benefit from native methods or polyfills with the same API?

Here is what jQuery.fn.sort looks like in the console of Chrome. It appears to be referencing the native sort:

    >jQuery.fn.sort.toString()
    "function sort() { [native code] }"

It is referencing the native Array.prototype.sort; I just wanted to make a native-only way.

Yes, you can use other native methods and polyfills with the same API, for example here is a jQuery plugin for reversing elements:

    jQuery.fn.reverse = [].reverse;

Reply on news.ycombinator.com