Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript? I've written some fairly complex jQuery selector over the years, perhaps I'm wrong but I something tells me that while the simple use cases can be done with plain old js the more complex selectors might not be so easy.
I find this debate so aggravating. I'm glad you can do some of the stuff jQuery does using modern vanilla js. Perhaps jQuery is overkill for doing one hide/show (or toggle) action on the page. But what about the more complex stuff. What is primary motivation behind this nagging issue, of the load time of jQuery?
I suspect it is that many developers have some obsession over shaving a few milliseconds on their load time. For jQuery? One library? Is it that bad that you need to write vanilla js? So you can save a few milliseconds?
Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass").
I like jQuery because the syntax makes sense, its clear and concise, you can do complex things with less code. Maybe some of the new stuff can be clean and concise and easy to read, but all of it? I have my doubts.
> Are you absolutely certain that everything that jQuery does can now be done in a clear and concise way using plain Javascript?
Can you give us some examples of things that you're worried can't be written clearly using plain JS? Obviously everything you can do with jquery you can do without jquery. Its just a library.
> Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read?
What do you mean by event delegation in this context?
> What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass")
document.querySelector / querySelectorAll supports this. Its available in all browsers on all platforms if thats how you chose to make web apps: http://caniuse.com/#feat=queryselector
> Can you give us some examples of things that you're worried can't be written clearly using plain JS? Obviously everything you can do with jquery you can do without jquery. Its just a library.
The not() selector for jquery is one. The closest() is another that I have used multiple times.
> What do you mean by event delegation in this context?
This is what event delegation looks like in jQuery;
$("ul#listid").( "click", "li.classThatMatters", function() {
//do something
});
How would event delegation look when selecting a child element with a specific class? Event delegation from scratch in vanilla js is longer than this.
I don't know much about query selectors. I'm going to read up on them. I suspect it handles most if not all the basic stuff jQuery does. However I suspect that are use cases that it might now.
If I understood your event delegation example correctly, I would use event.target.matches inside the event handler. Not the greatest support at the moment though.
And the Fetch API, has, according to caniuse[1], 76% support. I don't know that I can disregard 1 out of every 4 users, hence, jQuery.
For some things, like those mentioned by twhb, where support is >90%, sure, ditch the library and use the supported stuff. But I don't think all of jQuery is that well supported, yet, and/or has as decent an interface.
Polyfills are a good option in some cases. I, personally, try to stay away from them as much as possible. Once you add a polyfill (e.g. fetch), you' soon realize that you need another one (e.g. Object.assign) and soon you will have a list of polyfills to take care of. The advantage of jQuery in this regard is that it has all these "polyfills" in one place.
I believe that jQuery is not "modular" enough for today's web development environment. The "light" version is a step in the right direction but it's not enough. If one could configure the "modules" needed and download/load a single file/library, it would be tremendous.
Event delegation isn't native, but is now possible in five simple lines. That's the pattern: even when there's no native equivalent, new language features facilitate shorter, simpler implementations.
jQuery's performance impact is orders of magnitude worse than "a few milliseconds". On semi-old laptops and on mobile I've seen 200ms in just the time it takes to execute jQuery after loading it. There's also runtime overhead. It's not unbearable, but it's a real hit on a page with high user experience goals.
Native alternatives are often better–thought-out and better-integrated. For example, native Promises have better exception handling (thrown errors can be caught to continue down the "then" chain), more reliable execution order ("then" always defers callbacks, jQuery sometimes executes them inline), and integrate with `await`, like `const data = (await fetch("data.json")).json();`. (Though you should still transpile that, some browsers that don't support it are still in use.)
Besides that, unnecessary abstraction resists novelty and efficiency in the use of underlying resources.
I find this debate so aggravating. I'm glad you can do some of the stuff jQuery does using modern vanilla js. Perhaps jQuery is overkill for doing one hide/show (or toggle) action on the page. But what about the more complex stuff. What is primary motivation behind this nagging issue, of the load time of jQuery?
I suspect it is that many developers have some obsession over shaving a few milliseconds on their load time. For jQuery? One library? Is it that bad that you need to write vanilla js? So you can save a few milliseconds?
Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass").
I like jQuery because the syntax makes sense, its clear and concise, you can do complex things with less code. Maybe some of the new stuff can be clean and concise and easy to read, but all of it? I have my doubts.