jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people could use them as needed. No one library is going to provide everything for every project but making everyone require your ajax code when all they wanted was an `offset()` function is equally backwards thinking. We have much better tooling now to work with modules and to reuse code.
Arguments about CDN caching are some sort of premature optimization (or I don't know what really). Most early projects don't need it and other projects can trivially use many of the free (or super low cost) CDN providers if they care that much.
My issues with jQuery are not at how awesome it has worked in the past or how well it has hidden/handled lots of browser quirks; it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. The things jQuery does well would be useful within smaller components or libaries but now we are back to the original issue of jQuery is one giant blob.
I don't understand how the presence of jQuery on a page forces you to think that way (or any specific way).
The third is just noting that a jQuery function doesn't work in some contexts.
The fourth and fifth (which, like #1, are two lines from the same comment) are just documenting a try/catch block because something jQuery is doing might throw an exception.
The sixth is legitimately working around a browser issue, but it's not something you'd need to worry about unless you wanted to write that jQuery function. Like, it doesn't actually cause problems — it's just necessary to make that jQuery function return the exact value that they want.
The seventh is just an attribute named "support".
So far it looks like this isn't actually a list of reasons you will need jQuery, but a list of places where the string "support" occurs in the jQuery source. The fact that so few of them actually have anything to do with the compatibility of client code kind of undermines the point the author is trying to make.
As the author, I can assure you they are what I claim them to be: Points in the source code that identify some issue in some browser.
> The first two are actually the same thing,
Whoops! I thought I had removed the first one. Thanks for the bug report. The second is true, we received bug reports when we used we had issues with "use strict" in Firefox. I removed the first one anyway.
> The third is just noting that a jQuery function doesn't work in some contexts.
Wrong, it's a note about IE reporting the wrong value.
> The fourth and fifth (which, like #1, are two lines from the same comment) are just documenting a try/catch block because something jQuery is doing might throw an exception.
Because a particular browser has abnormal behaviour.
> The seventh is just an attribute named "support".
I thought removed that. It matched "support:", so you're still wrong.
> So far it looks like this isn't actually a list of reasons you will need jQuery
Accept that it does with the exception of two things I thought I had removed.
You owe me an apology.
I don't know exactly how many of the issues are real. Since of the ones I listed only 3 of 5 were real even by your count, I'd be surprised if none of the others were at all questionable. But even if we accept that they're all real, hair-on-fire problems with vanilla JavaScript, I still think you're going too far. At the very least, jQuery is not the only library out there that handles compatibility issues. Lots of people who use other libraries do not "need jQuery."
Basically, I think you have made a much broader claim than you have been able to support so far. I'm absolutely not trying to knock the hard work of the jQuery team or suggest that jQuery is useless. If you had just said, "jQuery is still really useful. Here's a few things it does for you that you'd never think of," I'd have said, "Great post — thanks for reminding everyone." Instead, you took a very hard line that came off as pretty combative, but your supporting examples were really shaky. So I disagreed.
http://www.amazon.com/Pinzon-Egyptian-Cotton-725-Gram-6-Piec...
For your tears.
Kinda surprised with the downvotes considering the poor intentionally provocative OP.
The more DOM APIs means even more need for jQuery. Stuff like Node.bind() and Object.observe() are some samples that need to polyfilled to make it work in all your modern and badass browser!
Not because 32k is too much data, but because it's just not in line with how I envision dependencies anymore.
It's not about jQuery being too many bytes, it's about the idea that A. for many things you can just use the browser APIs now, and B. for those handful of things that need libraries, make them targeted and replaceable.
Beyond all that, if you use a custom build of jQuery, you can't really trust that any library requiring it will actually work, returning to the original point: Libraries should try to not depend on jQuery, so you can enjoy your custom build in peace.
document.querySelectorAll('div').forEachRather than everyone reimplementing their own utility libraries, here we have one central library already cached by most areas of the internet, being maintained by some of the brightest developers in JS, and provided free of charge.
If your site permits, you are probably using the Google CDN hosted version of jQuery. If not, you should. If you can't, then your users can handle some 80kb one time load for a tremendous reduction in development time and increased consistency between browsers (let's be honest, cross-browser testing is a pain and we avoid it as much as possible).
So many people think that by using jQuery your code must immediately be bad. Spaghetti code is code with bad structure, jQuery does not enforce any structure so any bad code that includes jQuery is not the library's fault. I also believe (I don't have evidence for this) that this thought tends to occur amongst people who have learned front-end development using jQuery because it was very accessible, and then moved on to something else, and then looking back at their old, cruddy code developed negative feelings towards jQuery itself. jQuery doesn't care how you structure your code; you can use jQuery (admittedly with some difficulty) with Angular, Backbone, or any other popular framework. But you can't use Angular with Backbone. Arguments against jQuery that attack poor code / structure / "prettyness" are completely misrepresenting jQuery as a library.
In that same vain, jQuery is not slow. How you use jQuery, just like how you write your vanilla JS, is what determines performance. Some jsperfs show jQuery being slower than vanilla JS or lodash/underscore, but that's because jQuery is checking for many more things. You don't have to use jQuery if you know how to improve critical code, and you really shouldn't. However, it allows for you to write code quickly, without much complex thought for validating against edge cases at a very negligible performance reduction.
The former, over time more people load less code, as they move to the new browsers.
The latter, code doesn't decrease, but overall the amount of dead code increases, as people move to the new browsers.
That's the cause of all this criticism of JQ now.. Over time, more of JQ code becomes dead or unnecessary as these functions are subsumed into the native browser.
It is often simpler to reuse this functionality that people have worked on optimizing across a large number of browsers than it is to spend the time to reimplement that functionality myself. I can better spend that time getting a new feature working.