The reason I don't use jQuery these days is because other libraries serve jQuery's functions a little better for me.
* If I want a more robust interface for my XHR requests, there are a ton of nice libraries out there. Superagent is a good example.
* If I need utility belt stuff, I can get more out of Lodash, Ramda, etc.
* If I want animations, there are much better ways to do that nowadays, even with just basic CSS3.
* If I need distinct DOM lookup and manipulation...well, this might not be needed at all if I'm doing an SPA (in React, etc.). That said, there are compelling alternatives that I like, such as bonzo.
And then there's just the fact that you can now do an awful lot with bare Javascript.
So my argument against jQuery is less "jQuery sucks" and more "I prefer using all these other tools that cover the same surface". jQuery is still a marvel for all the conveniences it provides, and I don't think anyone should stop using it just because the cool kid says so.
jQuery is going to select and manipulate elements, but it's not going to compensate for when the developer does moronic things like creating DOM elements a bajillion times with HTML strings in jQuery every time something changes, animating things in improper ways(like animating dimensional properties that cause extra redrawing before postrender), etc.
There's nothing wrong with using jQuery. I just find that I don't even need it and would much prefer to just use existing APIs in its place. If there's a compatibility issue, I can install a polyfill that's much smaller than jQuery ever will be.
Nope. If you like it, and you don't have performance problems for which jQuery is a significant contributing factor (which is extremely unlikely), then keep using it.
Back in the day when you had to target IE-6 that made sense - the web was so broken you really needed something it jQuery to render it sane. But that time has gone now, and I can't count the number of times the jQuery solution actually used more core than raw js.
Doing this is positively harmful. Not only is it slower and creates clashing dependencies because library A wants jQuery version B, but library Y wants version jQuery Z, it forces the programmers to learn the 10'th different way of doing something (there are always at least 10 libraries that do it). It's unnecessary because there is one thing every javascript programmer should know (and it's not jQuery) - it's modern javascript and the standard library provided by a IE9+ browser. If it can be done with a few lines that then that is how you should do it - because it makes like so much easier for those who follow you.
1) If it's not on your resume it needs to be. 2) If it's already on everyone's resume you must seek alternatives 3) Resumes are never finished, only abandoned
I'm starting to feel like I should expand this into a manifesto.
<sarc> Yes, let's give the clueless tech recruiters more ammunition to screen out otherwise qualified candidates after someone with a blog stumbles across your site and suddenly recruiters are doing machine learning-matching on resumes against "the manifesto" </sarc>
The most recent project I took over had jQuery loading on every page. Even though jQuery was actually only used on maybe 10% of the pages. And the thing the previous developer was trying to accomplish with jQuery can be easily done in CSS.
Needless to say, that web site is now jQuery free.
There's a whole lot of complexity due to cross platform browser compatibility, working around various quirks, especially in the event handling plumbing, etc. It provides some nice conveniences, but if you're not using them, you're still paying for that big fancy layer.
Also, jQuery's APIs tend to be very polymorphic and fuzzy and interpretive, taking different numbers and types of parameters, supporting multiple overloaded interfaces, wrapping and unwrapping proxies, sniffing parameter types and shuffling them around, applying various defaults and shortcuts, bending over backwards to be "fluid", etc.
That kind of dynamic code has a cost and doesn't optimize so well, compared to the simple crisp unambiguous calls with with regularly typed parameters directly into native code that the newer standard DOM APIs tend to provide.
But the worst thing about jQuery isn't its own fault, it's the way people use it. I've seen so much jQuery code that repeats selectors and other slow searching method calls again and again because the programmer apparently thought calling into jQuery was faster than using a local or instance variable, doing the expensive computation once, then re-using the result.
Or maybe it's because using local variables doesn't match with jQuery's "fluid" style of chaining method calls. As if it was bad luck to break the chain of method calls by using a local variable and giving something a name.
And many people tend to use jQuery as a crutch to avoid learning and using JavaScript itself. (This explains all the excitement about that jQuery plugin that adds and subtracts numbers.)
https://github.com/cbrandolino/jQuery-basic-arithmetic-plugi...
So, if your site is small and has medium to low traffic, there's not really a "good" reason.
But if you have high traffic you might want to really squeeze every saving you can
(The article says: "[...] when you consider that we have over 5 million pageviews to the article content type in any given 30 days, it translates to roughly 150GB of bandwidth saved." But that is utter BS that wouldn't pass a sniff test with a 10-year old who understands a modicum of browser caching and network caching.)
I think the trade-off is that you opt for a more wholistic approach or framework that is more costly to bootstrap but easier to maintain, especially as complexity increases.