Vanilla JS, fast, lightweight, cross-platform framework

Post by lukeschlather » Sun, Aug 26, 2012, 10:46 PM UTC

dgreensp wrote: post #86

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 b…

Post by vidarh » Sun, Aug 26, 2012, 11:00 PM UTC

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.

Post by dag11 » Sun, Aug 26, 2012, 11:22 PM UTC

v413 wrote: post #29

dag11 wrote: post #18

Earlier quoted context omitted.

I'll take $('p').text('Hello.') over for (var p in document.getElementsByTagName('p')) { p.innerHTML = 'Hello.'; } any day!

This enumeration is done the wrong way. You enumerate over a DOM node list which looks like an array, which includes enumerable properties like "length". This means that the variable "p" at some point will be "length" and "length".innerHTML = "..." will produce an error. The proper way is: for( var i=0, ps=document.getElementsByTagName('p'), len=ps.length; i < len; i++) {ps[i].innerHTML = 'Hello.';}

Post by kellishaver » Sun, Aug 26, 2012, 11:24 PM UTC

masklinn wrote: post #77

kellishaver wrote: post #67

Earlier quoted context omitted.

jQuery is kind of a big download for mobile, so I often skip it for small tasks. What gets me is when people include jQuery and then further bog things down by loading a lot of plug-ins to do things that could easily be accomplished by adding a few lines of code of their own. Even if you do need and include jQuery, it doesn't mean you have to use it for every piece of javascript in your app. Many times, a plug-in wil…

> jQuery is kind of a big download for mobile, so I often skip it for small tasks. That's what Zepto[0] is for: jQuery's API, 20% of the size (although it drops some features, e.g. $(selector) is pretty directly proxied to document.querySelectorAll, so $('> .foo') works in jQuery but blows up in Zepto) [0] http://zeptojs.com/

Post by dasil003 » Sun, Aug 26, 2012, 11:57 PM UTC

MatthewPhillips wrote: post #94

vidarh wrote: post #93

Earlier quoted context omitted.

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.

Mobile isn't a niche.