Being aware of the direct benefits of libraries having things wrapped in a package, making daily work easier, my question is leaning more towards the fact that many features not implemented in HTML/DOM/CSS, has become available using these libraries.

There is everything, from visual effects (13 a dozen) to more functional oriented, to choose from.

As I see it today, 2014, with HTML5 and CSS3, more and more of these libraries seems to have played there role, as a kind of a bridge covering the gap between older browsers non capabilites and the new ones ability to handle it built in.

Whats more, is that these libraries also seems to drop older browser support little by little.

This gives me as a developer a hard decision, if to upgrade to next version with more functionality and lose old browser support, or stay on an older version with less functionality but with old browser support and the need of custom development to achieve new functionality.

So my question is, is there anything else I might have missed, which could affect whether to implement a library as a base or use raw JavaScript and add a library when it is really needed?

  • 3
    As I understand it, JavaScript libraries such as JQuery became popular because they made it possible to write code that would work on most browsers without changes. Consequently, it because possible to shift more work to the client side without the unimaginable pain of trying to get your complex JavaScript to work in different browser. It was a dark, terrible world before the JavaScript libraries. Mar 5, 2014 at 14:32
  • Can't argue with you about those "dark days", though as of today, if one count out too old browsers, the differences becomes less and less as the browsers starts to support the standards better and better, where I mean the libraries become less important in solving compatibility issues
    – Asons
    Mar 5, 2014 at 14:49
  • Fair point, thought the sheer convenience of using CSS selectors to retrieve DOM elements is enough reason to use a library for me - though I could just use sizzlejs.com directly in that case. Mar 5, 2014 at 14:53
  • As long as your business is fine with dropping those older browsers. We still have to support IE6 due to a couple clients in China and Japan, although luckily only as much as "the site can be used, but it doesn't have to look good".
    – Izkata
    Mar 6, 2014 at 1:49

3 Answers 3


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:


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.

  • Matching elements like that is kinda contrived, I don't know anyone who would use is over $el[0] == $otherEl[0]. But other examples make sense, although several show there is no simple way without rewriting one of jquery's functions yourself.
    – Izkata
    Mar 6, 2014 at 1:45

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.


Not the answer you're looking for? Browse other questions tagged or ask your own question.