Hello / Blog / Should you drop jQuery? - 3 Strikes.

I’ll start by admitting that I have a strong bias against jQuery. I don’t think it serves any legitimate purpose anymore, though it definitely did a few years ago. I don’t believe it’s poorly written or failing to keep up with the times or anything like that, the jQuery people do good work. The web has shifted significantly (obviously) in the past few years, leaving jQuery-like frameworks behind. Native JS is leaps and bounds better than it was when jQuery first came on the scene, and with ES6 we won’t even need pseudo-langauges like Typescript or Coffeescript anymore. We’ve simply moved past the point where we need to include a large, monolithic library on the page in order to make a few simple AJAX requests and select DOM elements.

Strike 1: loading multiple copies

The problem comes down to having a codebase that any developer can jump into without too much handholding. jQuery fits that requirement because everyone knows it, so it’s shoved into every component, widget and module simply because it’s easy to use. How many times are your components loading the library? How many times are 3rd party components loading it? More than once?

# module-1
$framework->addScript(JS_PATH + '/jquery-2.0.0.js');

# module-2
$framework->addScript(JS_PATH + '/jquery-2.0.0.js');

# module-3
$framework->addScript(JS_PATH + '/jquery-2.1.4.js');

Congratulations, you’ve now loaded 96kb of jQuery for (probably) no good reason. How about 3rd party extensions? Easily the worst offenders in my experience.

Strike 2: laziness in disguise

One thing developers love are the helper functions, like .each or .ajax. I’m a firm believer that if you’re loading the whole jQuery library to utilize functions like this you’re not a developer at all because you don’t understand how to write those functions yourself. If you can’t do this you don’t know Javascript. Don’t cheat yourself out of learning something just because it’s hard to understand at first.

Yes, vanilla JS is far more verbose than jQuery. It’s a lot less pretty to look at, but you’re only fooling yourself if you think you are simplifying your code by not writing standard JS. All the variables you didn’t declare are still created, loops still executed, and timeouts still set, you’ve just reduced the visibility (and thus maintainability) in order to “write less, do more”.

// jQuery

// vanilla JS
var should_remove = document.querySelectorAll('div.should-remove');
for(var i = 0; i < should_remove.length; i++){

These two are functionally identical. One took slightly longer to write and is far more verbose (look at that variable declaration, how disgusting), the other looks a lot neater but requires an entire library in order to work.

Strike 3: never learning “why”

Pretty self-explanatory. I’ve seen many developers that learned the framework first, or just stopped right there and never bothered to learn the underlying language, who get stumped by simple feature requests because it’s not bog standard jQuery. If you don’t know why something works and can’t think outside the box, what right do you have to call yourself a developer? To be fair, jQuery enables this behaviour but is by no means the only offender here. I’d say NodeJS is the worst offender because it tries to twist JS into a server side language (something it was never designed to be), but that’s a post for another day.

You need to be able to rewrite the following snippet in standard JS in under 10 minutes without Googling if you intend to call yourself a Javascript developer.


Wrapping Up

Pick any project or product which uses jQuery and see how many strikes you get. Look over the codebase, see how you’re using it. I almost guarantee you will not like what you see. Any more than 1 strike and I would strongly suggest a rewrite.


Rolling your own jQuery-like object is so easy that I don’t understand why that isn’t the preferred method for building web components. Creating your own shortcut methods increase your understanding of Javascript and give you complete control over your source code. Using jQuery? Well, your source code might look neater and more uniform. Not to say you can’t achieve that with Javascript, I’ve seen terrible code written in both. For projects of all sizes, executing only exactly what you need is far superior to loading 32kb of JS when you may only need a few bytes.