5 ms·

Also in the native version, you know you're only doing the work required. The jquery one will be doing a lot of extra useless inefficient grunt work to achieve

Also in the native version, you know you're only doing the work required. The jquery one will be doing a lot of extra useless inefficient grunt work to achieve nothing. Making it incredibly slow in comparison.

vidarh 14y ago
Premature optimization, and all that. It is trivial to get raw dom nodes out of jQuery, so you can easily use jQuery to begin with and replace any code with the full DOM API calls should it every become a performance issue. This discussion is a bit like how assembly programmers used to defend not moving to a high level language long after the performance benefits were not worth it any more.
- eugenes 14y ago
  I am rather curios now if it is possible to write the first pass in jQuery and then "compile" intelligently to native code like you would have written by hand. ;)
- MatthewPhillips 14y ago
  > This discussion is a bit like how assembly programmers used to defend not moving to a high level language long after the performance benefits were not worth it any more. But we're not at that point in the web yet. The performance benefits are worth it. Just try out JQuery Mobile if you want to see what wasted CPU cycles can do.
  - lukeschlather 14y ago
    It depends on what you're trying to do. Mostly, I try to write code that displays the same in every possible browser without special-casing or using confusing idioms. CPU cycles are cheap. A webpage that loads a little slow is a possible lost sale. A webpage that fails to load is a definite lost sale.
  - vidarh 14y ago
    It may be worth it for specific use cases, just like there are certainly still specific use cases where assembly shines. The point is we're well past the point where grasping for the asm-equivalent from the start should be the default unless you happen to specifically target one of those niches.
    - MatthewPhillips 14y ago
      Mobile isn't a niche.
      - dasil003 14y ago
        That depends on the application.
- tripzilch 14y ago
  > It is trivial to get raw dom nodes out of jQuery, so you can easily use jQuery to begin with and replace any code with the full DOM API calls should it every become a performance issue. That's still going to be a lot of work if the performance issues turn out to be many separate jQuery calls spread all over your code, which is not unlikely.
rhizome 14y ago
The jquery one will be doing a lot of extra useless inefficient grunt work Such as?
- xionon 14y ago
  "Useless" is subjective, but the jQuery object does a lot of extra work above the vanilla example. $ isn't just a syntax layer on top of querySelectorAll. When you do $('p'), it first queries the DOM for everything that matches that selector, then it creates new jQuery objects to wrap each of the returned nodes as well as creating a jQuery object to contain them. If all you're doing is setting the innerHTML of these objects, it's a non-trivial overhead.
  - Xion 14y ago
    It creates just one jQuery object to wrap the entire array of DOM nodes. Afterwards, .html() is essentially innerHTML [1], provided jQuery can use it directly (otherwise it has to create DOM nodes by itself). [1] https://github.com/jquery/jquery/blob/master/src/manipulation.js#L219 https://github.com/jquery/jquery/blob/master/src/manipulatio...

vidarh 14y ago

Premature optimization, and all that. It is trivial to get raw dom nodes out of jQuery, so you can easily use jQuery to begin with and replace any code with the full DOM API calls should it every become a performance issue. This discussion is a bit like how assembly programmers used to defend not moving to a high level language long after the performance benefits were not worth it any more.

eugenes 14y ago
I am rather curios now if it is possible to write the first pass in jQuery and then "compile" intelligently to native code like you would have written by hand. ;)
MatthewPhillips 14y ago
> This discussion is a bit like how assembly programmers used to defend not moving to a high level language long after the performance benefits were not worth it any more. But we're not at that point in the web yet. The performance benefits are worth it. Just try out JQuery Mobile if you want to see what wasted CPU cycles can do.
- lukeschlather 14y ago
  It depends on what you're trying to do. Mostly, I try to write code that displays the same in every possible browser without special-casing or using confusing idioms. CPU cycles are cheap. A webpage that loads a little slow is a possible lost sale. A webpage that fails to load is a definite lost sale.
- vidarh 14y ago
  It may be worth it for specific use cases, just like there are certainly still specific use cases where assembly shines. The point is we're well past the point where grasping for the asm-equivalent from the start should be the default unless you happen to specifically target one of those niches.
  - MatthewPhillips 14y ago
    Mobile isn't a niche.
    - dasil003 14y ago
      That depends on the application.
tripzilch 14y ago
> It is trivial to get raw dom nodes out of jQuery, so you can easily use jQuery to begin with and replace any code with the full DOM API calls should it every become a performance issue. That's still going to be a lot of work if the performance issues turn out to be many separate jQuery calls spread all over your code, which is not unlikely.

rhizome 14y ago

The jquery one will be doing a lot of extra useless inefficient grunt work Such as?

xionon 14y ago
"Useless" is subjective, but the jQuery object does a lot of extra work above the vanilla example. $ isn't just a syntax layer on top of querySelectorAll. When you do $('p'), it first queries the DOM for everything that matches that selector, then it creates new jQuery objects to wrap each of the returned nodes as well as creating a jQuery object to contain them. If all you're doing is setting the innerHTML of these objects, it's a non-trivial overhead.
- Xion 14y ago
  It creates just one jQuery object to wrap the entire array of DOM nodes. Afterwards, .html() is essentially innerHTML [1], provided jQuery can use it directly (otherwise it has to create DOM nodes by itself). [1] https://github.com/jquery/jquery/blob/master/src/manipulation.js#L219 https://github.com/jquery/jquery/blob/master/src/manipulatio...