Seriously?

[acrm]

Guys, your comprehensive list of equivalent codes in native JS (and I believe it's the best equivalent that possible for native JS) for the most useful functions of jQuery--actually it's the best demonstration, why I shouldn't move from jQuery. Many of native examples are much longer, some of them determinately brain-blowing ($el.height() equivalent makes my day!), and absolutely all of them are less laconic and readable.

Why on Earth should I write el.classList.add(className); if I could do simply $el.addClass(className);? Does anybody here read about Law of Demeter?

jQuery provides the finest Facade for all this native stuff. It will be great if in some future standard of ES will be included all jQuery functions with efficient native implementation in browsers. Till then I will use jQuery, because I consider code elegance and maintainability is the first priority.

If I found in my application a crucial performance issue with some jQuery function I can use instead of it an equivalent native code from your list (and great thanks for you for this!) and hide its ugliness under some jQuery-like wrapper function.

I hope that I do not offend anybody and not overreacted, just proportional for your overconfident title.

[iskyd]

Don't forget the initial purpose of jQuery, it was created to avoid the compatibilty from browser to browser. Now browsers are becoming more and more standards compliant, that means that jQuery initial purpose is out.
jQuery become the king of quick and dirty, just because it attracted a lot of "mediocre" developers because it's "easy to understand".
So as developer I really hope to don't find a jQuery app based because at 90% of times is equals to a quick and dirty things that keep you hours and hours to understand.
Then what about user experience? Why you have to make someone download also jQuery plugin? We are in the mobile era. We can't include a lot of plugins just because it is "easy to understand" and make your life easy (just your life, because others developers and user will hate you).

[acrm]

jQuery become the king of quick and dirty, just because it attracted a lot of "mediocre" developers because it's "easy to understand".

There is two part: first, it's "easy to understand", that's why most of newbie's apps are made on it. More experienced developers might use it less due to the same reason why some Basic developers don't want to move to modern languages--they get used to, and want to stay on familiar language, even though alternatives is better. Baby duck syndrome. And jQuery in comparison to JS looks like quite different language.

And second, "mediocre developers tends to q&d code", and let us assume that most newbies are mediocre. They will write q&d code not because they use jQuery, but because they mediocre. They will write q&d code on any language. JS do not constrains developer to good code style. jQuery also don't, but at least it gives to developer well-written abstractions, that, without it, good developer will write himself and newbies mostly won't.

I seriously doubt that qualified programmer can write on vanilla JS code, that will not be less elegant and readable than code, written by same-level programmer with jQuery. Cause vanilla JS code will be built of such ugly pieces as in comparison list. And jQuery code will be written with fine, laconic pieces.

We are in the mobile era

We live in LTE era, and 85 KB per site--it's nothing.

We can't include a lot of plugins just because it is "easy to understand" and make your life easy (just your life, because others developers and user will hate you).

User will get more frequent updates of functional and bugfixes, cause code will be more maintainable. And any programmers feel disgust for others code or even their own old one. Also don't forget for Baby duck syndrome. But, again, that code will be more maintainable.

[andrew-kirfman]

Some of these JQuery substitute examples here are laughable. Code should, first and foremost, be intent revealing. Calling something like $el.siblings() or $(document).height() is intent revealing in that I know exactly what is intended when one of those functions are used. The native Javascript examples provided on the other hand, are not intent revealing. I honestly don't know how you can say with a straight face that developers can read that code in less time and with fewer headaches than the JQuery equivalents.

I find it idiotic that someone would outright refuse to use a tool for the things that it is extremely effective for. You're essentially going through extra trouble to avoid using a tool on some twisted principle (i.e. that JQuery is somehow the devil, I suppose?).

In that, I'm not saying that JQuery doesn't have limitations. I'm only saying that you shouldn't completely exclude it from use just because of those limitations. It literally costs you almost nothing to include it an a project. You'll get it for free more often than not because your users will have the jquery file cached in browser already from a CDN.

[camsong]

Right now there is no need to debate this again. This repo helps a lot of project to update their tech stack, so it's serious for sure, but it's not a must. jQuery is also commonly used in many projects.