You might not need jQuery: A 2018 Performance case study

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

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

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

The task required to put 10.000 new elements with a class inside a target element. 10.000 elements could sound exaggerated, but the purpose was stressing the competitors a bit.

jQuery test code

The common (and the worst) way to accomplish the task:

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

Vanilla JS test code

The right way to accomplish the task in plain Javascript:

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

To measure the performance I run my scripts on Chrome Profiler tool.

Results

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

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

Why jQuery is slower?

Let’s have a deep look at the stack call:

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.

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

So, what now? Should you avoid jQuery in every project?

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.