The case against jQuery
Tags: javascript, webdev, frontend, jquery
Published: 2019-11-25 18:11:05

# The Good

jQuery was a great library. It made manipulating the DOM and adding listeners  very easy in a time where javascript wasn't as mature as it is today. It saved programmers a lot of trouble making sure your code work properly in all browsers. The syntax is very user friendly and easy to learn.

However, These same great features of jQuery makes it the pain that it today. When I started working in frontend development, I was introduced to jQuery at the same time I was introduced to javascript. I was hooked up immediately. Why wouldn't I? The Web API implementation varied widely between browsers and all the good plugins out there depended on jQyery. 

# The Bad

Since every time I needed to manipulate the DOM I imported jQuery, I didn't even bother to learn how it's done. Neither did my colleagues. And it is a wide spread problem. Many developers think of javascript as jQuery. A small look into stackoverflow shows how a lot and a lot of people answer javascript questions using the jQuery API. You have to say vanilla javascript or without jQuery to get a proper answer and still you would get answers like "you should use jQuery" :( A simple search for any DOM related javascript question on google shows the same problem (The term *vanilla javascript* is a conundrum on its own. Check this cool satire website about [vanilla js](http://vanilla-js.com/).

This is a trap that many falls into. Instead of learning javascript, the web api, then jQuery, the order happen in reverse or maybe it never go further that just learning jQuery. It's like learning Rails without learning Ruby. Once things get a bit complicated you'll be in hot water and you're stuck with using the framework even when it's not needed. 
Add to that the confusion it produces to whether a variable is a native javascript DOM element or a jQuery wrapped one.

If you use a frontend framework you will see how much the code becomes polluted if you wanted to manipulate the DOM with jQuery since all framework rightfully pass native DOM elements. Not to mention that jQuery encourages writing spaghetti code. Some of the reasons behind it is the lack of structure standard associated with it and the ability to chain DOM selectors

# The Ugly

You can say "I learned javascript properly and when I don't want to use jQuery I can just do it". Well it's not that easy. Almost every javascript library is jQuery plugin. The responsive design libraries like Bootstrap and foundation, WordPress, select 2, fancy box, and many other frontend libraries are *dependent* on jQuery.

That adds at least 82.54 KB of initial load required download to your website (for the minified version). Not to mentioned that jQuery sacrifices performance to be able to do its magic. The need to include it anyway lures developers to use it in their code anyway and the hole keeps getting deeper.

# Opposing Arguments

### Cross-browser support

The web api difference between browsers has dropped significantly since the introduction of jQuery. Not to mention that browser use sparsity are much more concentrated nowadays in Chrome as the browser (not that I'm happy about it ¯\\_(ツ)_/¯) and it is closer to the latest versions of whatever browser they are using since the update process is much easier today.

You might say that your users use some ancient IE version you need to support. Well luckily this argument does't live anymore since you can use the [Babel](https://babeljs.io/) project to support any list of browsers and versions you like. Plus Babel is not a run-time dependency so no performance overhead are added.

### The shortcomings of javascript

A strong argument for jQuery was that javascript used to produce a lot of boilerplate. Functions like `$.inArray()` or ​`().forEach` use to overcome a painful way of array iteration in javascript. However, alternative (`forEach` and `Object.keys()`) has been existing for a long time and supported IE9+. Javascript has evolved a lot since ES5 and even for browsers that have limited feature support, using a transpiler is far better that using a run-time libary. 

### I don't use react (or Vue) so I use jQuery

Does it really need to be either or? :) 

### Animation libraries require jQuery

There are many alternative lightweight animation libraries that doesn't require jQuery such as: [draggable](https://shopify.github.io/draggable/), [smoth-scroll](https://github.com/cferdinandi/smooth-scroll) and [sortable](https://github.com/SortableJS/Sortable).

# How can I help?

Make sure to use native javascript DOM manipulation. Many websites can help you find the alternatives syntax and show you how easy it is: http://youmightnotneedjquery.com/

Another way is to support and use lightweight libraries that do not depend on jQuery. [Rails removed jQuery as a dependency since 5.1](https://blog.bigbinary.com/2017/06/20/rails-5-1-has-dropped-dependency-on-jquery-from-the-default-stack.html). [Github ditched jQuery last year](https://github.blog/2018-09-06-removing-jquery-from-github-frontend/).  [Bootstrap 5 will not depend on jQuery](https://news.ycombinator.com/item?id=19147466 ), and I listed many animation libraries above.
You can also share here the libraries you like using which doesn't depend on jQuery.

Do you have a reason why you personally use jQuery or do you think it has a place today? please share in the comment and I will be happy to discuss it.