3

I've seen lots of posts comparing the speeds of various selector queries and DOM traversal methods. Of course it matters in cases with hundreds or thousands of elements and O^n operations, but does speed really matter in the 99% of cases where Jquery does some DOM manipulation (or whizzy animation, or makes toast) in response to a user action?

Won't almost all JQuery actions be faster than a round-trip to the server?

It makes sense to design uber-optimized server-side code. And it makes sense to be responsible with memory allocation and clean up in javascript so the user's browser doesn't run like Flash circa v5. I don't see any sense in wasting time optimizing the speed of JQuery / Javascript unless something noticeably slows the page down during testing.

Could somebody please tell me if and why I should start caring about JQuery speed?

Edit

My tone is admittedly whiny but not meant to be argumentative. There are good resources on how to approach optimization when you need to here, a better way to ask my question would have been:

What is the impact of sub-optimal Javascript / Jquery?
If I don't notice it, should I worry about it?

Accepted

After reading the responses I think the best answer to this question depends on your project and team size. In situations where programmers don't have a full view of the page the user will see, such as teams where

  • programmers are responsible for individual features on a page
  • programmers develop and unit test independently
  • there is a bespoke front-end API or other code which could impact actual response times

Then it makes sense to be more careful and 'prematurely optimize' as routine. This is feasible in cases where there are specialist, professional front-end designers who do nothing else.

On smaller projects, such as my current two-man team:

  • the lack of specialization
  • the need for high programmer output
  • the concentrated responsibility for the entire front-end in one person

All push optimization down on the priority list. @Anurag's answer helped me get to the core of the question and make the best decision.

Community
  • 1
  • 1
RSG
  • 7,013
  • 6
  • 36
  • 51

5 Answers5

7

Actually it doesn't make sense to optimize anything prematurely, not just jQuery.

The time and effort spent adding those micro optimizations is probably not worth the gains. If something is visibly slow, then dig deeper into the issue, but otherwise focus on designing the application well.

Creating good applications is not an easy, and trying to optimize too early can often lead to convoluted and difficult to maintain designs and architectures.

Anurag
  • 140,337
  • 36
  • 221
  • 257
3

I actually wanted to vote for closing the question as subjective and argumentative, but I guess this isn't about beeing argumentative.

The question we should ask here is, why shouldn't we optimize our code ?

I have to admit, ECMA-/Javascript interpreters did improve like a lot over the last years, so the overall Javascript performance increased. However, Javascript in a browser environment is still not really fast. Especially when it comes to DOM manipulation it's actually pretty slow (or: it can be really slow).

There are numerous great books about this topic, one I highly recommend is High performance Javascript by Nicholas C. Zakas.

To name a few reasons why we should optimize our code are:

  • Not all users have a cutting-edge browser, we should guarantee that users with old and slow browser also have a good user experience
  • Javascript in general, still has limitations. That means the memory usage is limited aswell as the execution time
  • Javascript & the browser UI thread can't execute parallel. That means slow'ish Javascript will effect the user experience like a lot
  • It's a good practice after all! If you're used to write optimal code, you'll do it every time, which I think is a very good thing

Even with a highly abstracted framework like jQuery, you can easily do terrible things. To give on example, a simple query statement like

$('body > *')

is almost always terribly slow. The problem is, even this statement wouldn't noticeable slow down things, but if you aren't aware of this and you write all your code without optimizations, it will add up finally.

jAndy
  • 231,737
  • 57
  • 305
  • 359
2

If your code is slow, jQuery won't likely be the bottleneck. It's fast for what it does.

More likely, your algorithm will be the problem.

Matt Howell
  • 15,750
  • 7
  • 49
  • 56
1

You should care when it starts to matter.

That is, performance should be a specific requirement of your applications and, as with any application, you shouldn't spend too much time worrying about performance until the lack thereof impacts some requirement. Of course, I'm not saying use O(n^3) algorithms when there is a simple linear alternative but bottlenecks can occur in many places and your JavaScript library of choice is just one of them.

maerics
  • 151,642
  • 46
  • 269
  • 291
0

jQuery helps you focus on your development rather spending hours fixing cross browser incompatibilities. Speed is not an issue, at least not to the naked eye. It all boils down to how your code is written and optimized. It doesn't mean you will stop using javaScript, but for tasks like ajax requests, life is allot easier with jQuery without having to worry about cross browser incompatibilities.

UPDATE Read comments below. This is what i used to test the javascript's for vs jQuery's $.each functions. jQuery wins by 4ms locally. jQuery 11ms vs javaScript 14ms

var array = new Array();
for (var i = 0; i < 10000; i++) {
    array[i] = 0;
}

console.time('native');
var l = array.length;
for (var i = 0; i < l; i++) {
    array[i] = i;
}
console.timeEnd('native');

console.time('jquery');
$.each(array,
function(i) {
    array[i] = i;
});
console.timeEnd('jquery');
Hussein
  • 42,480
  • 25
  • 113
  • 143
  • The difference between a 2 and 160 ms response time in the context of UI is negligible IMO. Is this done with JSLitmus? – RSG Mar 02 '11 at 08:17
  • @RSG you're right in that you should only optimise when there's a problem. However, 160ms response puts it on the spectrum of human perception. If your UI is going to take *at least 160ms* then you need to think about optimising or providing 'doing something' feedback to users. – johnhunter Mar 02 '11 at 08:28
  • 1
    The graph results i posted where incorrect. I was using console.time to go over a loop, I had syntax that affected the results. I updated my post, See above code used to test. After trying this again, It shows that jQuery's `$.each` is faster then javaScript native `for`. – Hussein Mar 02 '11 at 09:02