Assuming that people doing jQuery are maintaining legacy code is not necessarily right.
In my company, there is no people trained on modern front-end ecosystem (and they do not want to learn), and the only thing they know is a bit of jQuery. More than this, the main proprietary business tool they use (a survey program for online surveys) makes an extensive use of jQuery.
Being the only developer in the team I had to think what to do when they asked me to develop a new module for this tool. I did integration tests with React and the result was bad: the host tool is fully based on jQuery and it's DOM is based on a visible layer plus an invisible layer, what makes impossible to integrate, for example a React virtual DOM in it without messing up badly with the whole thing and write awful code.
After considering this, I decided to use jQuery and I am happy with it. I integrated it with a simple client side templating system and some other modern tools (transpiling, etc.) and I think we delivered a very strong product.
Depending of the situation jQuery can still be the good choice and I actually think that in some situations, choosing tools that are not adapted to your use case only because they are the de facto trendy ones can be harmful.
By the way, I tend to think that jQuery still is the dominant front end library in use (I have no source for this assumption though). People who say « it is sad [they] still have to use jQuery» in their legacy project makes a mistake because if you use jQuery in a modern way, it is totally possible to create some maintainable code, refactor old code using modern practices and make your life easier.
Remember jQuery is only a tool among other and that the new tools like Vue, React and Angular benefit of a powerful hype those days that tends to make us think that old tools are not good anymore: but those are only tools. It's still up to you to do something good or bad with them.
Actually, some people who have seen the code for my jQuery project expected a mess of spaghetti code, which is not at all!
I told them spaghetti code is not framework exclusive, nor a jQuery requirement.
It's bad programming practice, and it can happen on any and every framework.
Do you call Babel and Polyfills « Vanilla JavaScript » ? It's already JavaScript with super-powers.
There are people who do jQuery and who doesn't know how to set up those kind of environments. And their company don't want them to learn and/or they aren't interested to go further on their own.
I don't say it is good, and it should surely be avoided, but the simplicity of use of jQuery is for sure a great plus. Overusing it at a certain point for complex applications today is surely a mistake and the tools you mentioned should be used in most of the cases.
Assuming that people doing jQuery are maintaining legacy code is not necessarily right.
In my company, there is no people trained on modern front-end ecosystem (and they do not want to learn), and the only thing they know is a bit of jQuery. More than this, the main proprietary business tool they use (a survey program for online surveys) makes an extensive use of jQuery.
Being the only developer in the team I had to think what to do when they asked me to develop a new module for this tool. I did integration tests with React and the result was bad: the host tool is fully based on jQuery and it's DOM is based on a visible layer plus an invisible layer, what makes impossible to integrate, for example a React virtual DOM in it without messing up badly with the whole thing and write awful code.
After considering this, I decided to use jQuery and I am happy with it. I integrated it with a simple client side templating system and some other modern tools (transpiling, etc.) and I think we delivered a very strong product.
Depending of the situation jQuery can still be the good choice and I actually think that in some situations, choosing tools that are not adapted to your use case only because they are the de facto trendy ones can be harmful.
By the way, I tend to think that jQuery still is the dominant front end library in use (I have no source for this assumption though). People who say « it is sad [they] still have to use jQuery» in their legacy project makes a mistake because if you use jQuery in a modern way, it is totally possible to create some maintainable code, refactor old code using modern practices and make your life easier.
Remember jQuery is only a tool among other and that the new tools like Vue, React and Angular benefit of a powerful hype those days that tends to make us think that old tools are not good anymore: but those are only tools. It's still up to you to do something good or bad with them.
Why I'm still using jQuery in 2019
I wholeheartedly agree with your post.
Actually, some people who have seen the code for my jQuery project expected a mess of spaghetti code, which is not at all!
I told them spaghetti code is not framework exclusive, nor a jQuery requirement.
It's bad programming practice, and it can happen on any and every framework.
I created super tasty spaghettis using React by the way!
What are some things jQuery is good for -that you can't already do with vanilla Js?
What implementation of "vanilla JS"?
I don't actually work with these things, but I did learn that when you're supporting browsers back to IE 6, jquery is very handy.
JQuery is excellent at browser compatibility: you just use it's simple-short-to-write functional syntax and it runs everywhere.
Doesn't it remind nicely the JVM?
Writing modern js is easy to get full compatability with babel or polyfills
Do you call Babel and Polyfills « Vanilla JavaScript » ? It's already JavaScript with super-powers.
There are people who do jQuery and who doesn't know how to set up those kind of environments. And their company don't want them to learn and/or they aren't interested to go further on their own.
I don't say it is good, and it should surely be avoided, but the simplicity of use of jQuery is for sure a great plus. Overusing it at a certain point for complex applications today is surely a mistake and the tools you mentioned should be used in most of the cases.
Is it though? When do you pull in a polyfill? Is it for every JS feature you use? Did you remember to check the compatibility guide?
Im not saying you want to go without testing, but testing is all about figuring out what is not needed to be tested.