Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vanilla JS, fast, lightweight, cross-platform framework

vanilla-js.com

Post reply on HN
Print view View original

81–90 of 134 posts

Re: Vanilla JS, fast, lightweight, cross-platform framework

#81

Post by eugenes »

vidarh wrote: post #45
mibbitier wrote: post #28

Earlier quoted context omitted.

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.

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.

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

Re: Vanilla JS, fast, lightweight, cross-platform framework

#82

Post by jfaucett »

pooriaazimi wrote: post #72

Question: is the 'Speed Comparison' for real? I find it really, really hard to believe. Surely jQuery & co. revert to native implementations (if they exists, as they do in all modern browsers) for things like `document.getElementById` and don't iterate over the whole DOM.

I just looked at the latest jquery and its each statement does not do a native fallback, which really surprised me. Also you have to keep in mind that a simple $('a.active').each(someFunc), has to run through the a lot of jq luggage, plus the initial http fetch of the library (which has come under criticism for its size).

Re: Vanilla JS, fast, lightweight, cross-platform framework

#83

Post by jdlshore »

paulrosenzweig wrote: post #30

Was anyone else surprised by the performance penalty of jQuery? Over 400x hit for getElementsByTagName! I'm curious whether this is more due to cross browser checks or determining the what type of selector was used. To the source!

It may just be illustrating the problems with micro-benchmarks.

Re: Vanilla JS, fast, lightweight, cross-platform framework

#84

Post by masklinn »

paulrosenzweig wrote: post #30

Was anyone else surprised by the performance penalty of jQuery? Over 400x hit for getElementsByTagName! I'm curious whether this is more due to cross browser checks or determining the what type of selector was used. To the source!

> Was anyone else surprised by the performance penalty of jQuery? Over 400x hit for getElementsByTagName!

Not really. Just replacing document.getElementsByTagName by document.querySelectorAll (the native, browser-implemented version of what jQuery does) will generate a 150-200x perf hit depending on the browser.

The reason for that is twofold: first, getElementsByTagName doesn't have to parse the selector, figure out what is asked for, and potentially fall back on explicit JS implementation (jQuery supports non-native selectors. In fact, I believe you can implement your own selectors). But the parsing overhead should be minor in this precise case.

Second, the real reason for the difference, getElementsByTagName cheats something fierce: it doesn't return an Array like everybody else, it returns a NodeList. And the nodelist is lazy, it won't do anything before it needs to. Essentially, just calling document.getElementsByTagName is the same as calling an empty function. If you serialize the nodelist to an array (using Array.prototype.slice.call), bam 150~200x perf hit.

See http://jsperf.com/vanillajs-by-tag/2 for these two alterations added to the original "vanilla JS" perf cases.

There is a significant overhead to jQuery, but it's ~3x compared to the equivalent DOM behavior, not 400x.

Re: Vanilla JS, fast, lightweight, cross-platform framework

#85

Post by MatthewPhillips »

vidarh wrote: post #45
mibbitier wrote: post #28

Earlier quoted context omitted.

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.

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.

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

Re: Vanilla JS, fast, lightweight, cross-platform framework

#86

Post by dgreensp »

aneth4 wrote: post #75

Given how optimized jquery is, does anyone understand why something as simple as getting an element by id would be so much slower than Dom methods?

I'm surprised by the number of comments like this.

jQuery has to parse the selector and figure out that it's of the form "#id". This requires running a regular expression. A lot more is happening.

The whole jQuery call from start to finish takes 2.85 microseconds, in what is presumably a real benchmark, but microbenchmarks like this are hard to interpret and basically meaningless. But yes, if your app needs to do a burst of 350,000 jQuery calls in a tight loop and you are bummed that the whole thing takes a full second, you should then optimize using document.getElementById.

Re: Vanilla JS, fast, lightweight, cross-platform framework

#87

Post by MatthewPhillips »

ams6110 wrote: post #53
pooriaazimi wrote: post #49

Earlier quoted context omitted.

I'm sorry. I don't know if you're joking or are serious. But if you're a C programmer and have no experience with JS I guess it must be really easy to be fooled by this "joke". Some JS people (the ones usually with a long beard) hate how kids use frameworks like jQuery and this site is an attempt at telling them "The vanilla JS, i.e. the standard language that all browsers use and your cool jQuery leverage under the…

there's no block scope. Only function scope. There is global scope as well, and it's (unfortunately in most cases) the default.

Also there is block scope. let { ... }

Re: Vanilla JS, fast, lightweight, cross-platform framework

#88

Post by masklinn »

pooriaazimi wrote: post #72

Question: is the 'Speed Comparison' for real? I find it really, really hard to believe. Surely jQuery & co. revert to native implementations (if they exists, as they do in all modern browsers) for things like `document.getElementById` and don't iterate over the whole DOM.

> is the 'Speed Comparison' for real?

Depends what you mean by "for real". The document.getElementsByTagName comparison is bullshit: gEBTN is lazy, just calling it basically doesn't do any work, it just allocates a NodeList object and returns.

If you serialize the nodelist to an array or use document.querySelector instead (it returns an array) you get ~3x between the native version and the slowest libraries, not 400x.

Re: Vanilla JS, fast, lightweight, cross-platform framework

#89

Post by xionon »

rhizome wrote: post #52
mibbitier wrote: post #28

Earlier quoted context omitted.

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.

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

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

Re: Vanilla JS, fast, lightweight, cross-platform framework

#90

Post by lukeschlather »

MatthewPhillips wrote: post #85
vidarh wrote: post #45

Earlier quoted context omitted.

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.

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

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.
Post reply on HN