...when you're writing code that has to run at 60fps. The rest of the time, you categorically should always be using jQuery.

The native equivalent is very likely to be what jQuery is using under the bonnet, so jQuery is essentially just a wrapper most of the time. The performance hit from that wrapper is pretty close to zero. It's certainly nothing to worry about unless you're writing a game. The difference comes when jQuery isn't just a wrapper - likely for things where there are browser differences or performance improvements by doing things a different way. The majority of developers don't need to concern themselves with that sort of thing. We can just use jQuery and leave the performance 'hacks' to the jQuery team.

Additionally to that, mixing native and jQuery code makes things trickier to manage, especially if you manage a team of developers who don't all work the same way all the time. "Just use jQuery" is a good rule-of-thumb.

And lastly, jQuery has a vast pool of talent keeping up with browser tech better than you. Even the most avid follower of JS updates can't compete with a team of the standard jQuery draws upon. When a new method gets rolled in to the core of jQuery, something that speeds up selectors for example, your code improves without you doing any work. That'd a massive benefit.

(How much of a jQuery fanboy am I?!)

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.

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.

    $("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)
    });

    $("div").sort(function(a, b) {
      return a.clientWidth * a.clientHeight - (b.clientWidth * b.clientHeight);
    });

#Ex. 1

    $("div").map(function(){ return $(this).css('background-image'); })

    [].slice.call(documents.getElementsByTagName('div')).map(function(a){ 
    	return getComputedStyle(a)["background-image"];
    });

    $("div").sort(function(a, b){
    	return $(a).find('*').length - $(b).find('*').length;
    });

    [].slice.call(documents.getElementsByTagName('div')).sort(function(a){ 
    	a.getElementsByTagName('*').length - b.getElementsByTagName('*').length;
    });

I never said such thing neither; now that is 100% a straw-man.

  $("div").sort(function(a, b) {
       var $a = $(a);
       var $b = $(b);
       return $a.width() * $a.height() - ($b.width() * $b.height());
  });

http://jsperf.com/d97b341f-cfc1-4057-bdc9-60e80adb5cf6/2

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] }"

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;

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.

Why would you multiply those?

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.

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.

If you're building games or working with a team who does, I'm going to guess you're working with fairly edge functionality in browsers where javascript support is great. If you're building sites for clients who are still (sigh) using IE7 internally, you just can't get away with something quite so simple.

As another commenter mentioned: "Even the most avid follower of JS updates can't compete with a team of the standard jQuery draws upon. When a new method gets rolled in to the core of jQuery, something that speeds up selectors for example, your code improves without you doing any work."

This is the same reason I use a library for preprocessing my CSS. I'd rather update a gem and trust a team whose focus is processing CSS than try to rely on myself for keeping up to date with the pace of the CSS WG and browser vendors.

Also, for anyone wanting to dig around the jQuery source, James Padolsey made a great tool for it. I know I was pretty amazed to find out just how much is going on under the hood. http://james.padolsey.com/jquery/#v=git&fn=

As such, they need to keep the API standard between versions. Unfortunately, they don't appear to have settled on the best API yet, so are constantly working to improve it.

I doubt the functions you are seeing removed[1] from 1.9 are specific to 1.9 being special or dual released with 2.0. They were more likely just removed because they were at the end of their deprecation cycle.

[1]: http://api.jquery.com/category/deprecated/

[1] https://github.com/jquery/sizzle/blob/master/sizzle.js#L237

[2] http://jsperf.com/yui3-vs-jquery-selector-test-3/54

Target made $69 billion dollars last year, and employs 365,000 people; I'd say there's no shame in working there.

If the cushy software dev life leaves you unemployed at some point, and you need a working-class job to pay bills while you hunt for something more to your liking, how will you spin your snarky attitude to your interviewer?

  $('#foo').css('transform', 'rotate(5deg)');

Also, there are many scenarios where you can safely use things like querySelectorAll like browser extensions, WebGL apps, 2D canvas apps, (native) WebCam apps, WebRTC apps and many more. Furthermore, at this point is arguable how useful is to support IE8 and below.

And this article falls very short of what can be achieved with the native implementation. For example thanks to JS being prototypical you can borrow almost any method from Array to your NodeList.

    [].filter.call(document.getElementsByTagName('a'), function(e){
        return e.innerText === 'Brackets';
    });

I'm seeing this a lot, but IE8 is the highest "blue e that goes on the internet" on Windows XP.

Its a brave (consumer-facing) business that can dump 10% of its customers [1]

[1] http://gs.statcounter.com/#browser_version-ww-monthly-201305...

  function ajax(url, post_parameters, callback, data)
  {
  	var http = new XMLHttpRequest();
  	if (http != undefined)
  	{
  		http.open(post_parameters == '' ? 'GET' : 'POST', url, true);
  		http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
  		http.onreadystatechange = function()
  		{
  			if (callback != null)
  			{
  				callback(this.readyState, this.status, this.responseText, data);
  				// readyStates: UNSENT = 0, OPENED = 1, HEADERS_RECEIVED = 2, LOADING = 3, DONE = 4;
  			}
  		};
  		http.send(post_parameters);
  		return true;
  	}
  	else
  	{
  		console.log("no ajax..  sorry.");
  		return false;
  	}
  }

    var http = new XMLHttpRequest();
    if (http != undefined) {
        ...
    }

    var ajaxObject;
    if (window.XMLHttpRequest) {
      ...
    } else if (window.ActiveXObject) {
      ...
    }
    
    if (ajaxObject) {
      ...
    } else {
      //handle users without ajax
    }

    $.ajax();

So you're comparing the body of one function to the signature of another? I know I posted some really shitty code, but you managed to shoot yourself in the foot even in that scenario, grats.

https://github.com/jquery/jquery/blob/master/src/ajax.js

Here, now it's apples to apples.

That said, I have nothing against jQuery, but what used to annoy me was seeing Javascript questions being answered with jQuery snippets without anyone blinking, everywhere and all the time... you see, that's actually coming onto "my" turf and wantonly murdering there. That was too much, and if a "backlash" is needed to restore some sanity and balance, I say lash away.

This is what I expected jQuery 2.0 would attempt, and the shape most browser libraries will take in the not-so-distant future.

http://jsperf.com/leebrimelow-native-methods-jquery-dom

jQuery is starting to become less relevant as newer browsers start to include the same functionality natively, and I say that as a massive fan of jQuery.

You can do this:

    $(function() { /* handle onDocLoad */ })

For anyone who knows jQuery internals, does it check for browser compatibility on every call, or does it check once, and then hardwire up the correct methods for the next call?

My personal opinion: not using jQuery (or similar library) for normal webpages is premature optimization and it will hurt more than help.

[1] https://github.com/jquery/sizzle/blob/master/dist/sizzle.js#...