The most commonly cited reason is its size which is about 95kb in most minified versions. But considering the power & flexibility it gives to the developer (terse and simplified way to access selectors, events, ajax, etc.), is 95kb really that much of a huge deal in the digital age of 2019?
I don't think it's baseless, yeah, we send a lot of data, but if you only need a subset of jQuery that's covered by ES6 and the DOM API, why use it at all?
It shouldn't take a genius to tell you which is more readable, terse and preferable. Another quite common use of jquery is DOM selection. Anyone who tells you that document.querySelectorAll("div.foo") is more preferable to $("div.foo") need to have their head examined.
I think you're being too harsh. Personal preference aside, if the issue is the the fact that you have to type more, you can just alias:
Granted that its old, but its also rock solid in stability and doesn't need tweaks and updates every now and then like so many other libraries in the npm galaxy ecosystem
That is true, it's feature complete. But it's not easily compatible with the fact that most JS frameworks are moving away from directly updating the DOM, which jQuery does.
The ajax syntax of jquery is so powerful that it has become second nature to many JS devs
"Second nature"... it's just a matter of learning a new API :D and window.fetch has been around for years now, though I admit its API isn't great :D
It has its uses but we still have to recognize that ES6 and the DOM API provide a lot of the features jQuery brought to the table, builtin. Either way, there's no right or wrong choice in absolute terms :D
Thanks for mentioning document.querySelectorAll.bind, I didn't knew about that!
And window.fetch isn't a drop-in replacement for jquery's $.post() or $.get(), it has slightly different behaviors - it doesn't store cookies, so can't work with authentication for example. There is also the fact that it won't on some older browsers like pre IE9.
And window.fetch isn't a drop-in replacement for jquery's $.post() or $.get(), it has slightly different behaviors
But who said it should be a "drop in replacement" ? I don't like fetch that much but there should be no assumption that its API should be like jQuery, for what reason? They are different projects.
it doesn't store cookies, so can't work with authentication for example.
This isn't true, by default fetch sends auth headers and cookies for the same origin, if you're looking for cross origin support, just specify credentials: include
There is also the fact that it won't on some older browsers like pre IE9.
If what you're after is support for older browsers jQuery might make sense, it's just that your argument is as one sided as the one of the people you're citing in your post :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't think it's baseless, yeah, we send a lot of data, but if you only need a subset of jQuery that's covered by ES6 and the DOM API, why use it at all?
I think you're being too harsh. Personal preference aside, if the issue is the the fact that you have to type more, you can just alias:
That is true, it's feature complete. But it's not easily compatible with the fact that most JS frameworks are moving away from directly updating the DOM, which jQuery does.
"Second nature"... it's just a matter of learning a new API :D and
window.fetchhas been around for years now, though I admit its API isn't great :DIt has its uses but we still have to recognize that ES6 and the DOM API provide a lot of the features jQuery brought to the table, builtin. Either way, there's no right or wrong choice in absolute terms :D
Thanks for mentioning
document.querySelectorAll.bind, I didn't knew about that!And
window.fetchisn't a drop-in replacement for jquery's$.post()or$.get(), it has slightly different behaviors - it doesn't store cookies, so can't work with authentication for example. There is also the fact that it won't on some older browsers like pre IE9.But who said it should be a "drop in replacement" ? I don't like
fetchthat much but there should be no assumption that its API should be like jQuery, for what reason? They are different projects.This isn't true, by default fetch sends auth headers and cookies for the same origin, if you're looking for cross origin support, just specify
credentials: includeIf what you're after is support for older browsers jQuery might make sense, it's just that your argument is as one sided as the one of the people you're citing in your post :)