from http://youmightnotneedjquery.com –

“At the very least, make sure you know what jQuery is doing for you,
and what it’s not. Some developers believe that jQuery is protecting
us from a great demon of browser incompatibility when, in truth,
post-IE8, browsers are pretty easy to deal with on their own.”

From a certain standpoint, any given .js file could be counted as a rudimentary library — not officially a library of course, but one can write a handful of JavaScript functions wrapped up in an object that handle grunt work on the app/site you’re working with. That may as well be your ‘library’ for the purposes of that project, and if you can build against pure JS without, like, missing deadlines or pulling your hair out, it’s probably The Right Decision.

The website goes on to showcase JavaScript that will work for all browser up to and including IE8 if need be – but really, it’s a good question to ask yourself regardless of the project you’re tackling. Are you just toggling classes? Don’t have a ton of transformations? No need to rely on someone else’s code, even if it is jQuery.

Honestly some things look and read far better in pure JavaScript than jQuery anyway. Look at the aforementioned website’s example of comparison via jQuery:

$(el).is($(otherEl));

In JavaScript, this is reduced down to something far more intuitive (that’s an opinion, but really == and === show up in enough other languages that a journeyman would recognize this from convention and previous experience, arguably moreso than a function call):

el === otherEl

Now that may be a loaded example, if for no other reason than a common practice with jQuery is to ‘pre-grab’ and name your jQuery objects like so:

function(el, otherEl){
    var $el = $(el);
    var $otherEl = $(otherEl);
    return $el.is($otherEl);
}

But the point still stands, I think. Building a library on top of another library just to call convenience methods like removeClass() or hide() is taking the long way home.

There are libraries like jQuery that truly become less relevant today due to browsers finally catching up.

On the other hand, there are utility belt libraries like Underscore that you’ll end up reimplementing yourself on any moderately complex project. These are simple, focused utility functions that I like to use even on vanilla JS projects.

Then there are frameworks like AngularJS or Montage. These are wildly different beasts than jQuery. Whereas jQuery bridges browser gap, frameworks like AngularJS force you to adopt a completely different paradigm separating your UI in loosely-tied components that have declarative bindings to models. You won’t need these for simple websites, but for highly interactive single-page apps you can’t go far fiddling with DOM—even jQuery won’t save you from managing view lifecycle, updating data in many places on the screen when it changes, client-side routing, etc. Think apps like Facebook, Twitter.

Then there’s a neat niche for libraries that don’t force you to rewrite all your code like AngularJS, but still allow to build rich JS apps. My current favorite is ReactJS by Facebook, its killer feature is one-way data flow and what you may call declarative DOM programming: you specify how DOM tree looks in different program states, and ReactJS calculates and applies minimum set of DOM operations needed to go from one state to another.

As you can see, the space for JS frameworks is vast, and you shouldn’t dismiss all of them just because browsers are finally catching up with jQuery. There are more problems, and more solutions to client-side JS development, and the field is exploding right now.

It really depends on how much DOM manipulation you want to do. The nice thing about jQuery is that it gives you a fluent API for manipulating the document object model. If you don’t want something with as much weight, try Zepto, which is a jQuery compatible API that delegates to native browser methods, making it smaller in file size.

If you don’t need to do much DOM manipulation, then a JavaScript library might not be of much use anymore.