Slashdot Mirror

Actually less efficient: http://jsperf.com/leftpadding

I'm giving up moderation to post this but it has to be said. You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow. Both jQueryUI and jQueryMobile are designed to completely change (and unify) what the browser controls look like. Of course they are slower than native. I even went to your little site and ran this one : http://jsperf.com/jquery-body-vs-document-body-selector. jQuery came up about 5%-6% slower than native. If you give up a unified, well tested framework and a tenth of the development time for a 5% speedup you are either working on something very special or need to be fired immediately.

jQuery is not a performance killer. If it was you wouldn't see it on nearly every website more complicated than "hi my name is narcc". What it does do, however, is cut development time considerably. Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions. And provides far more web-specific features that Javascript does not (otherwise people wouldn't use it).

I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.

Just for fun: Just look at how readable and maintainable that code is. I'd love to try to figure out why a $100000 web-application isn't working in BroswerX 10 months after somebody else wrote it written like that.

Additionally: if you are doing 2+ million operations than yes maybe you might want to devote some time to writing a specialized function. But normally you're only doing less than 50 on a fairly complicated web-app so your benchmarks won't show too much of a difference there.

Just for my own fun. What happens if you go : document.querySelector('.menu > a:last') in IE9?

It's pretty well-known that jQuery is an absolute mess. A lot of effort has gone in to improving it, sure, but that sort of makes the point, doesn't it? Take a look through the code yourself. It still isn't pretty.

To call it "memory-lite" is just absurd. (Get a profiler and run some tests if you have trouble believing that.)

It's also hard to argue that a complex generalized solution to some problem will be faster than one written with a specific case or set of cases in mind. The abysmal performance of jQuery for even simple operations is evidence enough of that. (See any one of a zillion tests, or run a few of your own if you can't find one to your liking and you'll see what I mean.)

jQuery isn't stellar, obviously, but it makes jQuery UI and jQuery Mobile look positively light-weight in comparison! jQuery has often been blamed for PhoneGap's performance problems. Again, this is something you can see for yourself.

Even the most ardent jQuery fan will acknowledge that jQuery (expecially jQuery UI and Mobile) is a performance killer, they'll just say "it doesn't matter because computers are getting faster every year" or something equally silly in defense of their favorite library. To claim that jQuery is actually *faster* than a native solution is just crazy.

Just for fun

Go to http://jsperf.com/asm-js in Firefox 19: figures are the same for fast and slow.

Load the page in Firefox 22.0 (Mac OS X 10.7):

• fast: 6,539,184 ±0.48% ops/sec (74% slower)
• slow: 25,160,685 ±1.13% ops/sec (fastest)

They managed to optimise it to take four times as long to run the asm.js code in comparison to normal interpreted code. Great job!

Once you start having to create elements of the dom tree on the fly JQuery comes into its own in terms of writing less code and hence developers producing quicker results.

Looks like it takes the same amount of code to me. Also, the pure JS version is significantly faster as you can see from any one of several tests online.

Let's not forget about maintenance. The unreadable mess that jQuery forces you to write (to try to compensate for its absurdly poor performance) coupled with the ever-shifting API dramatically increases maintenance costs.

Nobody cares about efficiency any more

Your users care. They care a lot. The host of slow laggy UI's and the associated user complaints are a strong testament to this. The "computers are getting super fast" line has always been the cry of lazy and incompetent developers. Don't fall in to that trap!

Writing super efficient code is just not worth wasting time

That's why you should AVOID jQuery! You get a massive performance boost simply by avoiding it! You waste tons of time and effort already trying to get acceptable performance out of jQuery -- which ultimately leaves you with slower, less readable, and less reliable code in the end.

In short: Cutting out jQuery will ultimately save you development time, improve the overall quality of your code, and significantly improve performance. Why would you even bother with jQuery in the first place?

var array = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
var length = array.length;
for (length -= 2; length > -1; length -= 1)
{
array.push(array[length]);
array.splice(length, 1);
}

This is according to http://jsperf.com/js-array-reverse-vs-while-loop/5

I'm not saying there aren't issues with JavaScript. I'm just saying that it's not a terrible language, and the only arguments you have given against it are red herrings. Whether I am intellectually behind or whether the first JavaScript implementations were terrible are entirely inconsequential.

And what are the odds, if you didn't believe it from all the quarters of the internet it was already coming from? Such as, oh I don't know, just for instance, the authors of the largest, most complex, and most widely used rich-client Javascript applications?

The "largest, most complex, and most widely used rich-client Javascript applications" are quite possibly Firefox and Thunderbird. The difference is that the intellectually backward Mozilla developers want to see JavaScript evolve, whereas Google wants to toss it entirely and replace it with a new language of their own design.

I was â" for some reason, as thinking about this now it makes little sense â" hypothesising that the majority of callsites would have an immediate argument. http://jsperf.com/math-sin-cache/3 shows that in the case of having an immediate argument, in Opera at least (which is unsurprisingly what I know the perf characteristics of best), using a cache is significantly faster; Chromium is giving somewhat unstable results, showing between a 1â"5% difference between Math.sin and a cache; Firefox/QtWebKit both make Math.sin significantly quicker in the immediate argument case. Of course, in the case when the argument is largely polymorphic, property caches stop providing decent performance, and calling Math.sin becomes quicker.

I also never claimed that implementing floating point maths in JS using integer maths was quicker than using the native Number type (or made any claim about the relative performance at all), merely that within JS engines not everything is a double, and that there is (internally) a separate int32 type, so the performance wouldn't be quite as bad as was claimed (which is certainly far from any claim that it's going to be at all quick).