jQuery has a considerable performance cost for the abstractions it provides. It doesn't just call the native methods under the hood, it has to provide additional abstractions like chaining by wrapping every returned object into a jQuery object. In a lot of cases these abstractions aren't helpful because you need to understand exactly what jQuery is doing. If you compare the cost of native methods over what jQuery does you easily add 500 lines of javascript code on every method call.

Additionally, jQuery may not provide the abstractions you need or want. If you are using a high level framework that manages templating I would argue that you should use the abstractions designed by the framework and not the one-size-fits all ones that jQuery provides. There is a lot of functionality that jQuery provides that may not be relevant at all for you. jQuery animations are one example.

Using jQuery doesn't stop you from running into browser bugs. jQuery could help you out with basic things like selection and event handling but modern browsers are already much improved in this area.

I very much dislike the spaghetti code that over reliance on jQuery plugins results in. You have pieces of code that rely entirely on jQuery and can't be refactored out or reasoned with clearly. It is terribly unidiomatic in any case.

EDIT: That being said jQuery does have its place.

> jQuery has a considerable performance cost for the abstractions it provides ... add 500 lines of javascript code on every method call

But how much does this really matter, with modern high performance JS engines? The simple (and somewhat dismissive, I'll grant you) answer is of course it comes at performance cost, and it may be considerable. Comparatively. After implementing using jQuery, if some component is too slow, optimize. Rewrite using underlying core JS if you have to. Or better yet, reexamine what you are attempting and see if there's a better way.

> I very much dislike the spaghetti code that over reliance on jQuery plugins results in. You have pieces of code that rely entirely on jQuery and can't be refactored out or reasoned with clearly. It is terribly unidiomatic in any case.

Can you provide some examples of what you mean by this? Especially about it being unidiomatic (programming language idioms are a topic dear to my heart :)?

Personally, I find jQuery allows me to structure my javascript in a more coherent way, but that could have been greatly influenced by my relative experience with javascript before starting to use jQuery.

Search any jQuery plugin, many insert DOM and listeners that are not slightly configurable, most of them don't follow simple rules: http://coding.smashingmagazine.com/2011/10/11/essential-jque...

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

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;

This. It's very fashionable to be "NoJQuery" these days, but I just don't have the time to worry that there may be a particular quirk for getting, say, the selected value of a dropdown list for a particular version of Safari during a full moon.

Not only games. Animations, dragging, building DOM - all are critcal situatons where every line counts, all benefit for close to metal code, every ms adds up.

> every ms adds up

Especially when any bloat is multiplied times however many visitors come to your site. Presenting an efficient front-end to your users is the polite thing to do, as it saves them both compute time and personal time. A lot of efficiency can be gained with tricks like removing dependencies, minimization through gzip, and ahead-of-time compiling.

>Especially when any bloat is multiplied times however many visitors come to your site

Why would you multiply those?

Because number of milliseconds wasted on each visit * number of visits = total number of milliseconds wasted.

Yes, but no one person is experiencing that, so it doesn't really make a difference for user experience.

> The performance hit from that wrapper is pretty close to zero

Unfortunately, that's rarely the case in my experience. But I'd be interested in any hard numbers you have here.

https://news.ycombinator.com/item?id=2261211 and responses has some hard data from about two years ago, but it's possible that jQuery has improved a lot in the meantime, of course.

So _if_ you're at a point where you care about the performance of your DOM code, jQuery can end up as a significant bottleneck. Most people are not at that point, most of the time. But most people _are_ at that point some of the time. The trick is recognizing when they are and what to do then.

I disagree, use JavaScript since that what you're supposed to be doing, using jQuery for everything is stupid

Would you also suggest people not use frameworks, since using the core language is what they are supposed to be doing?

Additionally, I guess an ORM or query builder of any sort isn't worth it either.

I suspect for a large percentage of sites JS on the client may be faster than the language the site was implemented in (even at a pure language level, ignoring that you offload computing very efficiently).

Why is using abstractions that we all (well, many, if not most) believe to be of benefit on the server any different when run on the client, especially when it's more efficient (compared to server) and scales better?

Sure, if someone thinks they have a need for raw javascript performance but they haven't tested and confirmed this, maybe blind assumption isn't the best way to proceed.