ES5/ES6 have no bearing on whether someone should learn jQuery. Learn JavaScript first, then learn whatever other library you choose.

Here's the thing -

Almost no one_ _is doing new work in jQuery. There's a few small projects around, but I haven't seen a big-budget project that uses jQuery for a while. I've also seen it used for prototyping.

It's still really useful to know: because there's still tons of legacy jQuery code around, and understanding it will be necessary to work on updating legacy projects.

So, I recommend learning enough jQuery. Understand how the selectors work, and the $(document).ready() pattern. After that, learn as the need arises.

Nope. Everyone is trying to get rid of jQuery lately.

If you going to touch existing codebase or want to freelance you still definitely want to learn jQuery. If you work in startup or otherwise greenfield dev job there is no need. That said biggest reason why jQuery became popular is that it's so easy so learning. Learning it might not be such major undertaking.

Yes, having knowledge about the old Technology is important. Toddler programmers should at least know the basics of J Query since I believe while code reviewing this will help them a lot. Not only this learning a bit old language doesn't make them that much outdated as we can still find J Query in the web and applications. So it is not totally a waste of time.

Learn the fundamentals of JS first. If you have time, learn some libraries and Frameworks. Always remember that the fundamentals will stay the same, libraries and Frameworks fade. That said, long after something falls out of popular use there will be requirements for maintenance and adjustments. jQuery isn't dead yet.

No. Don't waste your time. jQuery is still used all over the place, but its days are numbered.

You won't find anyone advertising themselves to new employers as a "jQuery Pro". That'd be like applying to McDonalds and when they ask you if you can speak Spanish you respond, "No. But I do speak Latin, so I guess you could say I have a strong grasp on the grammar of romance languages."

Beginners should learn vanilla js first, then jQuery if they need it to work on legacy.

All of the answers posted so far are good but I'm not seeing 1 big glaring issue people are missing.

It's a privilege to work on New Code. If your just starting out or are new at a company or are doing freelance or maintenance - your probably not going to be writing new code or new sites. There are always bugs to fix; new features to implement on old websites or changes to existing websites.

JQuery for all of it's faults it may have (I still like it and use it when needed) is like Wordpress. It accounts for a very decent chunk of the internet. So in all likely hood, you'll come across existing JQuery code / sites and will need to work with them.

Should you learn it? Why not? It's not terribly hard to get a hang of and it's just another line item on your resume that someone else might not have.

I'll offer my 2¢. I went to school for graphic design - and while they did show us HTML and CSS, I've never had any computer science, programming, or JS training.

I had been building websites for around a decade, working in and around JavaScript, but never able to make any sense of it before I decided to try to really learn what was going on.

I struggled and struggled with the 'easy' jQuery code that promised to make everything simple, yet I was struggling to understand. To me it often felt like riding the train when you want to take a car - sure the train is fast, easy, and direct, but it doesn't always go to the locations you want to end up. Instead of getting in a car and going directly from point A to point B (your destination), jQuery has you making numerous 'simple' hops from Station A to Station F, then a simple hop over to Station E, then an easy ride to Station D which gets you kind of close to Station B. As you can see, all the 'simple' shortcuts can end up being a maze if you're trying to do anything slightly different than their pre-designated course. Trying to navigate your entire app like that ends up not saving you time, leading to code that breaks easily, and it still takes a lot of time and effort to figure out how to write.

Finally, I decided to try to write vanilla JavaScript with no jQuery and no other libraries. It wasn't until that moment that I was able to begin understanding what JavaScript was doing. The higher level of abstraction provided by jQuery had been serving as an impediment to learning what JavaScript was doing this whole time.

You know the craziest thing—even though in some cases jQuery saves you a few characters of typing, overall when you look at the total codebase, whenever I refactor old jQuery code into vanilla JS the vanilla JS version usually turns out to be smaller overall. It's funny how that works out, but it's happened more often than not.

So no, I don't think you need learn jQuery to learn JavaScript—it might actually be the opposite: ditching jQuery might be the key to learning JS!

Some websites that have helped me, even though I don't know the jQuery 'way' of doing things, are sites that show how things are done both in jQuery and vanilla JS. Whenever I want to learn how to do something I don't know at all, I check one of these sites and learn the vanilla JS way:

• youmightnotneedjquery.com
• gomakethings.com/ditching-jquery

Good luck! I've been on my learning journey for 4 years now and it's like a whole new world has opened up. I'm super excited for your journey and wish you all the best.

😍💻📜

I will tackle the question, assuming we talk about a beginner developer without much professional experience.

jQuery was created to simplify DOM manipulation through easy to use, cross-browser API. It may be tempting for a beginner to learn jQuery, because the library makes working with the DOM so pleasing:

jQuery:

$(el).fadeIn();

Vanilla:

function fadeIn(el) {
  el.style.opacity = 0;

  var last = +new Date();
  var tick = function() {
    el.style.opacity = +el.style.opacity + (new Date() - last) / 400;
    last = +new Date();

    if (+el.style.opacity < 1) {
      (window.requestAnimationFrame && requestAnimationFrame(tick)) || setTimeout(tick, 16);
    }
  };

  tick();
}

fadeIn(el);

For everyone new to JavaScript, the second example will look confusing and bewildering. But this is only because of the abstraction level jQuery provides. You can think of it as an iceberg - you see only the top of the iceberg, the small, beautiful part of it. But beneath it, there is an enormous piece of ice, hidden from our eyes.

My answer to your question will be no, I won't recommend a beginner to learn jQuery. And here is why.

Learn the basics

You possibly heard this a million times. Before jumping to any framework or library, learn the fundamentals. Learn pure JavaScript. It's OK to learn ECMAScript 6 in the process, it's actually a good idea to do so, but don't start learning React, Angular, jQuery or any other before having a strong foundation.

I've written a post about learning JavaScript, explaining how exactly my learning journey went

Marco Alka wrote another post about vanilla JavaScript vs JS libraries, which you should definitely check.

I have been tempted, more than I should, to start learning some new, awesome and promising library, but I resisted the temptation. You know why? Because libraries and frameworks fade, but knowledge doesn't.

Learn the fundamentals, have a strong foundation, become prolific JavaScript developer and just then think about what tool to learn.

Performance

jQuery ease of writing comes with its cost. Remember the example from before? The JavaScript example is 93% faster than the jQuery equivalent. Here is the proof - jsperf.com/fadein-to-native/1

Almost everything jQuery does, JavaScript does it faster. It may look that you are writing more code when using vanilla JavaScript, but that is not entirely true. Let's see how jQuery's fadeIn method looks like under the hood:

function (speed, easing, callback) {
    return this.animate(props, speed, easing, callback);
}

Well, that doesn't seems too bad. One line of code. But what's inside this.animate ?

function (prop, speed, easing, callback) {
    var empty = jQuery.isEmptyObject(prop),
        optall = jQuery.speed(speed, easing, callback),
        doAnimation = function () {

        // Operate on a copy of prop so per-property easing won't be lost
        var anim = Animation(this, jQuery.extend({},
        prop), optall);

        // Empty animations, or finishing resolves immediately
        if (empty || dataPriv.get(this, "finish")) {
            anim.stop(true);
        }
    };
    doAnimation.finish = doAnimation;

    return empty || optall.queue === false ? this.each(doAnimation) : this.queue(optall.queue, doAnimation);
}

Now that is something! You can see how much more operations the fadeIn method does, compared to our JavaScript example. This is where the difference in speed comes from.

The Library Trap

I like to call a person who invest most of its time learning a library or a framework, a "tool prisoner". I've been a tool prisoner once in my life. I started learning Backbone.js. It was a promising framework, used by several big companies. I've invested 3-4 months learning it. Right now, I cannot monetize my time learning Backbone anywhere. As of 2017, Backbone is on a steady decline. Here is the global interest drop:

Looking from the financial side, these 4 months were tragic. On the contrary though, I have learned a valuable lesson - libraries and frameworks fade, fundamental knowledge doesn't.

Yes, because it's still good at what it does. It has nothing to do with es6 that's just a new version of the JS-language so it's irrelevant to add this to the decision.

JQuery can be written in ES6 the problems jQuery tackles are not magically gone.

If you get a declarative project that delivers the payload in HTML you probably still will need such a framework. The ecco-system is alive.

Don't get me wrong complex pages that are highly interactive should be written in a "real" Frontend-Framework because state is one of the complex topics.

but writing a "low-budget" template or an static content page you probably could use jQuery for a slideshow or whatever.

Think of countries with bad internet they still use "progressive enhancements" because it's better to have a 4kb everything is useable but not fancy than a 4mb nothing works for 6 minutes fancy SPA.

Just saying know your customers, your target audience than decide .... absolutism is usually wrong

TLDR: No. But not because of ES6.

ES6 is a new version of the Javascript language. It has a lot of new syntactic sugar on top of plain old Javascript and it does, of course, improve developer productivity leveraging modules, a decent OOP-like syntax and a few other tricks.

jQuery on the other side is a library that helps with DOM manipulation.

The DOM is the virtual representation of a web page for your JS code. The standard DOM API are provided by the browser, and you can think of it as a "plugin" for JS to HTML nodes.

The problem has always been that the DOM API is terrible. Like so terrible that you don't ever want to use it directly. And each browser did things in a different way.

jQuery solved all of this by providing a lean interface to the DOM API, which is, by the way, uniform through all browsers. Bingo!

ES6 does not change in any way how you access the DOM. It only changes the language core.

So, "why you wouldn't use it then?" you may ask.

TLDR: CSS3 and React/Angular

90% of what I did with jQuery were animations and magic tricks on particular events. Now, if you have a deep knowledge of CSS, you don't need JS at all for this kind of stuff. _CSS Transitions, animations and transformations to the rescue. _They are faster, work well across many browsers and do not require scripting.

What remains of the jQuery use cases is today completely overridden by a proper Frontend engine like React or Angular (I do prefer React). Let them take care of the DOM.