You can basically sum up this entire rather ridiculous site with "Yes, you don't need jQuery, you can just use the built-in methods, but using jQuery is generally more pleasant, more consistent, and involves less typing". One particularly egregious example from the site:
The author summarises this, helpfully: "As usual, more characters, but still easy without jQuery."
Of course, if you were doing that remove class operation quite often, rather than writing all that code out each time, you might wrap it up in a helper method, and maybe you'd call it, I don't know, "removeClass" or something; perhaps if you were doing a whole bunch of DOM operations you might create little helper methods for each one, again to save you some typing. Pretty quickly you might end up with a little library of helper methods... and, of course, being a wonderful programmer who never makes mistakes, I'm sure that little library would be every bit as optimised, reliable, and correct as a battle-tested library used on hundreds of thousands of web sites.
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.
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.
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.
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.
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
Perhaps I'm being a bit dense (I've done prettymuch no front-end JavaScript), but since className gives a single string with class names separated by spaces[1], won't
fail if the element in question has more than one class? In that case, you'd need to get the className attribute, split it by spaces, do the replacement in the resulting array, and then join back and assign, I believe.
You're right it will only work for one class. This is actually a perfect example of jQuery smoothing out the rough edges for you. I think the split method would work (provided you remember to split with \s instead of just space). It actually took me a while to come up with a regex replace that won't break in some corner cases ( I think)
Actually since forever, you don't need to use document.getElementById("x") in any case. You just by putting the id to the element, it is already available to you referencing it by such id.
That won't work on Android 2.x, which doesn't support `.classList`. Performance isn't even an issue here since changing classes will cause a reapply-styles and layout.
Note the Jquery ticket for this issue can be tracked link below. In most cases Jquery will try to use to native implementations this is the ticket in this case they've never found it to be "miles away more performant".
That makes the site a pretty good illustration of one of the reasons why, although you don't have to use jQuery, you maybe should. With jQuery you benefit from years of development and testing, which your own code probably hasn't undergone.
Although, I do occasionally use jQuery, I'm more comfortable and productive when not using it. Also, if I shamelessly take a peek at jQuery's source now-and-then to see how they implement certain features so I can make a helper for it.
I agree that's a lot nicer. But it also looks like essentially a mechanical transformation. Instead of a runtime library (whether jquery or roll-your-own), would it be possible to handle cases like that via syntactic sugar that expands at deployment time, and doesn't require shipping a library to the end-user's browser? (Or does something like that already exist? I haven't really spent any time with CoffeeScript and other compile-to-JS languages, so it's possible they already have nice syntax for this kind of thing.)
> Instead of a runtime library (whether jquery or roll-your-own), would it be possible to handle cases like that via syntactic sugar that expands at deployment time, and doesn't require shipping a library to the end-user's browser?
You could, but that would require user-agent sniffing (and thus continuous maintenance), and would probably need a pretty unusual caching setup.
If I saw that, first comment on the PR would be to wrap that eye sore in a wrapper function with a clear name. Which is basically what jQuery is doing.
or you can use just what js you need instead of loading pages down with dozens of bloated js library's and wondering why your site sucks and is slow as a slow thing
This is exactly the point. I don't mind the extra typing in those first few examples because jQuery is mysterious and it's nice to cut through the mystery. However, I don't want to have to fill my code with conditional logic based on the user's browser - that's lame.
The real value of this site is not what it says, but rather a reminder that jQuery is an abstraction and is made of code rather than magick.
Of course, if you were doing that remove class operation quite often, rather than writing all that code out each time, you might wrap it up in a helper method, and maybe you'd call it, I don't know, "removeClass" or something; perhaps if you were doing a whole bunch of DOM operations you might create little helper methods for each one, again to save you some typing. Pretty quickly you might end up with a little library of helper methods... and, of course, being a wonderful programmer who never makes mistakes, I'm sure that little library would be every bit as optimised, reliable, and correct as a battle-tested library used on hundreds of thousands of web sites.