Looking at stuff like http://youmightnotneedjquery.com/ it's easy to see why there are lots of cases where jQuery just isn't needed anymore. But 10% of them still look very verbose without jQuery and when I'm working on a simple website the convenience of jQuery is worth it to me so I continue to use it where it helps.
But when you need to do more than that, you'll realize jQuery is still useful (assuming you don't use a framework or whatever). Either you will use something like jQuery or you'll reinvent by writing the methods yourself.
IMO it's still relevant, despite the hype of other frameworks.
In case you want to play with that - https://codepen.io/onion2k/pen/NQrEKq
• Array.from is comparatively recent to the web platform, and cuts out IE support.
• Learn when to use Array.prototype.forEach, and when to use Array.prototype.map: use forEach when you aren’t deliberately constructing a new array but are just wanting to call a function on each value, and map when you are applying a function to each value and care about the result. Otherwise you’re creating a new array unnecessarily.
• You can (and should) avoid Array.from when you just want to call an array method on an array-like object (e.g. NodeList, HTMLCollection, Arguments): instead, call the method directly on the instance; it’s OK, all the Array.prototype methods are deliberately designed to work on array-like objects, not just arrays. That is, instead of `Array.from(x).forEach(y)`, use `Array.prototype.forEach.call(x, y)`. Otherwise you’re creating a new array unnecessarily.
• A slight word of caution about classList: IE and very old browsers don’t implement it on SVG elements. Just take that into account if you support IE at all.
So then, you might end up with this:
Array.prototype.forEach.call(document.querySelectorAll('.foo'), (fooEl) => {
fooEl.classList.toggle('bar');
});
Or if you hate the `Array.prototype.` and `.call` bits, const forEach = Function.prototype.call.bind(Array.prototype.forEach);
forEach(document.querySelectorAll('.foo'), (fooEl) => {
fooEl.classList.toggle('bar');
});
And if you’re happy to drop a little more older browser support including IE, you can just use NodeList.prototype.forEach, which incidentally is normally the same function object as Array.prototype.forEach: document.querySelectorAll('.foo').forEach((fooEl) => {
fooEl.classList.toggle('bar');
});The jQuery equivalent for this is $('.foo').addClass('bar');
Such as?
In general, jQuery is an amazing wrapper around native JS with a saner API and countless hours of different browser quirk workarounds to make sure that what you try to do works in all modern browsers and IE.
Ajax calls are one example. JQuery ajax works everywhere, while fetch() will never work in IE without polyfils.
Not to mention all the other ES6 features IE refuses to support. Not every project wants or needs a webpack/ babel build process.
It does add a microscopic bit of weight to your page and some milliseconds to your load time, but that's it. It's a ressource that is smaller and faster to load than the content of the page. In my opinion, this argument is meaningless. Modern SPA frameworks are slowing the web way more. Loading your jQuery scripts async will make this transparent for the user.
In the edge-cases where jQuery is slower than native JS (because of polyfills, mostly), there's nothing stopping you from using those directly.
Unless you are Netflix and micro-optimizing your homepage to the millisecond, there's no hard reason to avoid jQuery. I believe that those slight performance losses are worth the trade for the benefits of using a strong and well tested framework that has browser support and lowers development time. I'd trust non JavaScript experts to use jQuery on my projects, I can't say the same for raw JavaScript.
Trend-driven development is a pitfall. Boring technologies are where it's at.
I’ve inherited a ton of backbone, angular, react projects and it’s always a pain sourcing devs for whatever random thing a project was written in 1-8 years ago. Jquery is just jquery and you can put anyone on it.
EXCEPT I reached out to the lambda school contractor program for a work project and was pretty shocked they only do node+react.
They only teach modern, relevant technologies? How shocking.
I didn’t say it was the wrong choice or even a bad choice, just that I was surprised. Ruby and jquery are certainly modern technologies.
My surprise was more a factor that maybe I had too high of an impression of LS (and I’m still a fan!). The blogs/tweets I’ve seen from afar made it seem more like a rigorous “be a working software engineer” curriculum. If their candidates are ONLY suited for a node/react stack that seems like a pretty dangerous/inflexible hire. TBF this was for folks who haven’t graduated yet, so maybe they go wider on their final few months. As a person who hires engineers, I don’t want someone who only knows one stack. I want smart people who can solve problems in any stack that gets thrown at them (even if they’re junior and I need to hold their hands a bit).