You might not need jQuery: A 2018 Performance case study

Marco Trombino
May 19, 2018 · 5 min read

The purpose of this case study is comparing Javascript performance and what is the cost of choosing jQuery as solution of any problem.

Why jQuery? It’s the most used Javascript library in the world and the most criticized one at the same time.


We all know jQuery and it doesn’t need any introduction: it’s easy to use and can manipulate web pages with few lines of code, so why shouldn’t we chose it blindly?

Well, I have to admit it: I used it a lot and, as many JavaScript developer, I started to use it even before Vanilla Javascript.


The power of Vanilla

Image for post
Image for post

No, it’s not another library, it’s just plain Javascript without additional libraries. To interact with the DOM (Document Object Model) it uses API standardized by W3C.

Given that web browsers can only understand plain JS, every front-end library must use it internally.

So there is no magic behind jQuery, just plain Javascript code wrapped up in a syntactic-sugar function.

But how much code is wrapped up? Well, actually a lot and even more than you could need.


The jQuery’s engine

Image for post
Image for post

As library, jQuery born to provide a collection of useful functions to manipulate the DOM.

The library’s core is the selector engine. With that, we can select and querying every kind of element and even create new ones!

To make it possible, jQuery has to perform a ton of operations to understand what you’re looking for. Behind the scenes it run an engine called Sizzle, which contains more than 2000 lines of code.

This fact brings us to the point: if you know what kind of manipulation you need, why let jQuery do a ton of operations instead of accomplish it with a simple API call in plain JS?


The case study

“Okay, jQuery isn’t the fastest, but does it really affect the performance?”

To answer to this question I put Vanilla Javascript and the latest jQuery release (3.3.1.min) side-by-side.

The task

jQuery test code

for(let i = 0; i < 10000; i++) {   $('#target').append($('<div />').addClass('test-div'));
}

Vanilla JS test code

const c = document.createDocumentFragment();for(let i = 0; i < 10000; i++) {   const e = document.createElement('div');   e.className = 'test-div';   c.appendChild(e);}document.getElementById('target').appendChild(c);

You can notice the strange method at the first line:

document.createDocumentFragment();

What is it? Mozilla sums it up for me:

DocumentFragments are DOM Nodes. They are never part of the main DOM tree. The usual use case is to create the document fragment, append elements to the document fragment and then append the document fragment to the DOM tree. In the DOM tree, the document fragment is replaced by all its children.

Since the document fragment is in memory and not part of the main DOM tree, appending children to it does not cause page reflow (computation of element’s position and geometry). Consequently, using document fragments often results in better performance

But maybe I could talk more about it in another article.

The tool

Results

Image for post
Image for post

As we could have expect Vanilla performed the task in 18,99 ms, whereas jQuery did it in 195,89 ms. Ten times faster.

Image for post
Image for post

Looking at the Timeline we can also see a big difference on the stack call for the Script Evaluation.

Why jQuery is slower?

Image for post
Image for post

As said before, jQuery wraps up a bunch of operations to accomplish the task.

The Script stack section shows every operation and the time taken to complete it.

Image for post
Image for post

We can clearly see that appending a node to the DOM requires just a single call for Vanilla, which interact directly with the DOM API, whereas jQuery run a lot of operations (the stack was too long to fit the picture). The difference is evident :

  • Vanilla: 4 ms
  • jQuery: 95.3 ms

Vanilla Javascript is almost 25 times faster than jQuery on append.


Someone could say:

“It’s just less than 200ms, who cares???”

It depends. There are situation where web applications need to update the dom continuosly (such as animations) and “micro-optimization” like this can make the real difference on avoiding jank.

Jank is any stuttering, juddering or just plain halting that users see when a site or app isn’t keeping up with the refresh rate.


Conclusion

Not exactly. The purpose of this article was to keep in mind that easier doesn’t always mean better and using “abstraction layers” can affect performance.

jQuery has a giant community who works constantly with the jQuery Team to improve the library release after release. Some features like AJAX integration or the endless plugins collection are excellent and ready to use.

On the other hand, including jQuery in your web page couldn’t be the right choose if you just need to select a div, also considering the library size itself.

Weight the pros and cons and choose the right tool for the job.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store