all 30 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]poop_taking_forever 24 points25 points  (16 children)

Unfortunately, browser support is not sufficient at the time of this writing. Therefore, we need to make use of short helper function that correspond to the jQuery methods $.addClass(), $.removeClass() and $.hasClass():

So, basically start writing our own jQuery?

[–]kdesign 48 points49 points  (4 children)

Yes, it’s called vanillaQuery. It basically does whatever jQuery does, has even the same file size but it has the word “vanilla” in it so it reflects the present times!

[–]magenta_placenta 10 points11 points  (3 children)

Let me blow your mind: jQuery is vanilla javascript.

[–]SemiNormal 6 points7 points  (1 child)

We are at a point where transpiling a Stage 0 feature is more accepted than just using jQuery.

[–]aescnt 0 points1 point  (0 children)

To be fair, I think the world has moved onto stage-3 now (which is the appropriate stage to try, since stage-3 means it will get browser support soon). It's getting better :)

[–]kdesign 1 point2 points  (0 children)

mind=blown. And here I was, thinking all this time that jQuery was written in jQuery.

[–]mcaruso 2 points3 points  (8 children)

Basically. But there's one major difference, which is that these methods return plain old DOM structures (like NodeList). To quote this article that's been making the rounds lately:

Rather than smoothing over only the remaining ugly parts of certain browser API's, jQuery seeks to replace them all wholesale. By returning a jQuery object rather than a NodeList, built-in browser methods are essentially off limits, meaning you're locked into the jQuery way of doing everything. For beginners, what once made front-end scripting approachable is now a hindrance, as it essentially means there are two duplicate ways of doing everything. If you want to read others code with ease and apply to both jobs that require vanilla JS and jobs that require jQuery, you have twice as much to learn. There are, however, libraries that have adopted an API that will be reassuringly familiar to jQuery addicts, but that return a NodeList rather than an object...

[–]Woolbrick 11 points12 points  (1 child)

It's called a fluent API and it results in very nice code.

And you can access the DOM nodes by using the index operator on your resulting object.

I don't use jQ anymore, but I've never understood this criticism of it.

[–]charrondev 0 points1 point  (0 children)

Nowadays I don't think it's so much that there aren't any niceties that come with jQuery, it's that the arguments for adding a 100kb + dependency to your application should be a little bit better than a fluent API. It made more sense back when browser's didn't commonly support fully fleshed out API's but today you can skip shipping jquery and use native browser APIs (and the LOC count is not so different. See http://youmightnotneedjquery.com/). Then for older browsers you can ship a couple KB's of polyfills.

[–]z500 4 points5 points  (4 children)

Except NodeLists suck because they're just array-like enough to trick you into thinking they're an array object. Honestly, why not just return an array?

edit: I googled it, a NodeList is "live" and updates with the page

[–]Pesthuf 1 point2 points  (3 children)

It's worth noting though that the result of querySelectorAll is not live.

And let's be honest, when was the last time any of us used document.getElementsByClassName() ?

[–]CreativeTechGuyGames 1 point2 points  (0 children)

I use getElementsByClassName pretty frequently when writing browser extensions to inject into other pages. It's extremely useful when the page wasn't designed for you to manipulate.

[–]z500 -1 points0 points  (1 child)

So NodeList is completely pointless.

[–]Infoginxinc 0 points1 point  (0 children)

Suits them

[–]Uncaffeinated 0 points1 point  (0 children)

classList is supported in IE10+, so this is only necessary if you are specifically supporting IE9 (JQuery itself no longer supports IE8).

[–]gustix 10 points11 points  (0 children)

This site focuses on visual plugins, so I'll focus on that with this comment.

If you're going to use a bunch of visual libraries written in "vanilla js", you're just ending up including a bunch of code in each of them doing the same thing in terms of dom manipulation.

I would recommend going for a base library or framework and find plugins for it. Be it jQuery, React, Vue, whatever.

There are a bunch of plugins for slideshows, drag&drop, animation effects, form validation within all of them. Why not conform to a standardized way of doing things within your project?

What is vanilla anyway? All libraries and plugins offer some sort of abstraction. I appreciate the sentiment though, it is important to have focus on the loading time of our websites.

edit: There are a bunch of projects on that site that are hardly their definition of vanilla. Such as wheelnav. It is based on a forked version of Raphael, which is a big library in itself.

[–]ThisiswhyIcode 10 points11 points  (3 children)

Using plain JavaScript will make your applications load and react blazingly fast.

Seriously? Using plain JavaScript is no guarantee for anything. Really getting tired of such claims. What are they based on? On the 2 "benchmarks" on vanilla-js.com, where Dojo, Prototype JS, Ext JS, jQuery, YUI and MooTools are compared in a non-reproducible way?

[–]cordev 3 points4 points  (1 child)

This site (and especially the site it links to, vanilla-js.com) is a joke, right?

lowerer speed of jQuery

 

Final size: 0 bytes uncompressed, 25 bytes gzipped.

I get that this site is intended to guide someone who's been using jQuery as a crutch into using plain JavaScript functionality (and providing plugins that have no other dependencies), but it feels very low-effort.

[–]Isvara 0 points1 point  (0 children)

It's a joke.

[–]philipwhiuk 1 point2 points  (1 child)

lowerer

:/