So when those new native api functions arrive, jQuery will start using them and gain some performance boost (using native vs. custom js code) while at the same time remaining backwards compatible (by doing feature detection). No one wants to write their own feature detection code so this whole page about using native apis is instead of jQuery is ridiculous.

If the point of that website was to educate people on the apis that jQuery calls under the hood, it chose a really poor name.

This a thousand times, I know with $.trim it will use trim() for good browsers and then whatever hack effort was necessary for IE8. It would be devastating to have to write this manually.

Exactly. "No one wants to write their own feature detection code" is the whole point of jQuery.

You hit the nail on the head.

Or you could use the class list polyfill.

If that's all you need, then that would be fine. However, for most projects you end up needing many other such polyfills, to the point that you might as well use one library—jQuery—to provide them all (plus a lot of other functionality).

Sure, the native APIs are slowly catching up, and classList is definitely a useful one.

You'd better hope that there actually is an element with an ID of "foo", though, otherwise your example will throw an exception. The last time I pointed this out here, there was some disagreement as to whether jQuery's behaviour is actually desirable. I think it is, but I'm probably biased from writing too much jQuery over the years.

`$(".foo").removeClass("bold")` becomes the wonderfully concise

    [].map.call(document.querySelectorAll(".foo"), function(node) { node.classlist.remove("bold"); })

With spread and fat arrows:

    [...document.querySelectorAll('.foo')].forEach(node => node.classList.remove('bold'));

This may seem anecdotal, but I can tell you from writing a lot of non-jQueryified code that with modern browsers, applying classes to dozens of elements dynamically can be an anti-pattern. 99% of the time, when doing something which previously would have required that, I can use a single class on a parent element.

Not if you're in an environment (like mobile) where you want to reduce repaint.

In which case you don't want to be using jQuery at all and should instead be using a virtual DOM implementation like virtual-dom, famo.us, react or mithril.

https://github.com/Matt-Esch/virtual-dom

What if you don't have the option to all of a sudden bust out a new framework? Some of these scenarios are just unrealistic.

No, you're going to mess with repaints and renders. It is not an anti pattern.

While I'm waiting for that, and still writing applications that have to support ancient versions of IE, I think I'll stick with Jquery. Can't wait for the future though

And in 5-10 years, we'll be able to use it.

before jQuery I always defined an ID method like:

   function ID(id) { return document.getElementById(id); }

saved some typing. I'll always try to use jQuery now though, bigger problems to solve.. few extra bytes to download is not that bad...

The day I can drop support for IE <10 will be a good day.

They said this about IE5 and 6 too.

Some of us still have to support IE6.