5 ms·

.classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot o

.classlist() [1] is coming [2]. It'll allow you to do: document.getElementById('foo').classList.remove("bold"); Sure, it's still more verbose. But a lot of what jQuery does is slowly being obsoleted by better native javascript apis. [1] https://developer.mozilla.org/en-US/docs/Web/API/Element.classList https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist http://caniuse.com/#feat=classlist

jhpriestley 12y ago
`$(".foo").removeClass("bold")` becomes the wonderfully concise [].map.call(document.querySelectorAll(".foo"), function(node) { node.classlist.remove("bold"); })
- sfeng 12y ago
  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.
  - usingpond 12y ago
    Not if you're in an environment (like mobile) where you want to reduce repaint.
    - malandrew 12y ago
      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 https://github.com/Matt-Esch/virtual-dom
      - ulisesrmzroche 12y ago
        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.
  - ulisesrmzroche 12y ago
    No, you're going to mess with repaints and renders. It is not an anti pattern.
- ahoge 12y ago
  With spread and fat arrows: [...document.querySelectorAll('.foo')].forEach(node => node.classList.remove('bold'));
eli 12y ago
The day I can drop support for IE <10 will be a good day.
- seanp2k2 12y ago
  They said this about IE5 and 6 too.
  - eterm 12y ago
    Some of us still have to support IE6.
mcmillion 12y ago
And in 5-10 years, we'll be able to use it.
bshimmin 12y ago
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.
Khao 12y ago
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.
- kyllo 12y ago
  Exactly. "No one wants to write their own feature detection code" is the whole point of jQuery.
- rip747 12y ago
  You hit the nail on the head.
- aplummer 12y ago
  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.
- malandrew 12y ago
  Or you could use the class list polyfill.
  - organsnyder 12y ago
    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).
taf2 12y ago
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...
- deleted 12y ago
  [deleted]
TheGunner 12y ago
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

jhpriestley 12y ago

`$(".foo").removeClass("bold")` becomes the wonderfully concise [].map.call(document.querySelectorAll(".foo"), function(node) { node.classlist.remove("bold"); })

sfeng 12y ago
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.
- usingpond 12y ago
  Not if you're in an environment (like mobile) where you want to reduce repaint.
  - malandrew 12y ago
    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 https://github.com/Matt-Esch/virtual-dom
    - ulisesrmzroche 12y ago
      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.
- ulisesrmzroche 12y ago
  No, you're going to mess with repaints and renders. It is not an anti pattern.
ahoge 12y ago
With spread and fat arrows: [...document.querySelectorAll('.foo')].forEach(node => node.classList.remove('bold'));

eli 12y ago

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

seanp2k2 12y ago
They said this about IE5 and 6 too.
- eterm 12y ago
  Some of us still have to support IE6.

mcmillion 12y ago

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

bshimmin 12y ago

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.

Khao 12y ago

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.

kyllo 12y ago
Exactly. "No one wants to write their own feature detection code" is the whole point of jQuery.
rip747 12y ago
You hit the nail on the head.
aplummer 12y ago
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.
malandrew 12y ago
Or you could use the class list polyfill.
- organsnyder 12y ago
  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).

taf2 12y ago

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...

deleted 12y ago
[deleted]

TheGunner 12y ago

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