CODEWITHSUNDEEP
javascriptjqueryperformance
user7492538
user7492538

Reputation:

Native JavaScript vs. jQuery - real-world performance vs. theoretical benchmarks

After a decade or so, I started to get into web development again. I set up a page with about 50 different input fields in all variations, which manipulate the contents of a div. Favoring performance over convenience, I wrote all the event handlers in native JS. Out of interest, I replicated the page using jQuery.

Now, in native JS I cannot really group any event handlers for those input fields, even if they do similar things. Creating them with a loop doesn't save much code either, since it's never more than 1-3 related input fields. In the end, I have a whole bunch of functions that look like this:

var input = document.getElementById('input');
input.addEventListener('input', function() {
    // do stuff
});
input.addEventListener('change', function() {
    // do stuff
});

The JS for that test page is about 20 kb (unminified). The replicated JS using jQuery instead of native JS is about 9 kb (unminified).

While researching jQuery, all the articles that advise against it would feature some benchmark that shows that after x million iterations of some method, native JS was x seconds faster than jQuery.

The question I ask myself is: How relevant is this in real-world web applications. I mean, aside from the fact that it took me about four times longer to write the native JS, wouldn't downloading more than twice as much JS slow down the viewer much more than a theoretical x millionth slower execution time per method?

Upvotes: 7

Views: 12090

Answers (2)

Yuriy N.
Yuriy N.

Reputation: 6087

From application user point of view, everything that happens in less than 0.1 sec happens immediately.

For user it is completely all the same if page element changed in 0.0999999 or in 0.0000001 sec. Despite last is 999999 times faster, this speed matters only for creators of new "superfast" frameworks and those naive enough who trades simplicity and speed of development for numbers that means nothing.

Upvotes: 1

Brian
Brian

Reputation: 2952

Is the load time significant?

Downloading jQuery is often negligible in many cases as it will be cached if using a CDN (https://trends.builtwith.com/cdn/jQuery-CDN - 13% of the top 10k sites)- I find writing using jQuery you'll often end up with smaller scripts (~50% reduction in your example) which can offset it a bit. However at 80KB+ jQuery can be a significant increase in a pages download if it's not cached (memory and CPU use is pretty negligible on modern devices). I find usually as a script grows the more likely it is to make use of jQuery(or another library for that matter) and the size reductions from using a library increase however it's rare that the size of jQuery completely is offset by these savings.

What about optimization?

Saving a few cycles often is pretty negligible also for a lot of methods - it's best usually to take the faster/easier development route then work on optimization as it's required (which may mean removing jQuery as a dependency but for many browser related cases DOM related operations are often the most expensive tasks). Straight up aiming for perfect optimization usually results in more bugs/problems that are more difficult to resolve.

Is saving those few cycles worth it?

If it's only a few ms (even up to like 20-50ms or so) in a method called once every 3-4s often the user won't even notice, but if you've got to make thousands or millions of calls to a method that takes a a few millionths or thousandths of a second then it might be a good idea to look at optimizing that particular method. One thing to also be mindful is the setup you're using to test performance as it may be significantly higher spec'd than your users. Browser profiling tools which are built into many browsers dev tools can assist in identifying optimization targets.

So to answer your question how relevant is this in real world applications?

For most methods and many use cases not at all - the download is often insignificant as it's likely to be cached and the majority of the code for many applications will not see a noticeable negative performance impact by using jQuery.

With that being said jQuery should not be used as a one size fits all solution - if only using a few features then consider using native alternatives SO has plenty of questions with people looking for native alternatives and there are sites such as http://youmightnotneedjquery.com/ specifically for this purpose.

Upvotes: 10

Related Questions