Quick Tip – jQuery Newbs: Stop Jumping in the Pool

Oops, forgot the pastebin link: http://pastebin.com/HCkXtW28

That is a valid point. I modified the test slightly. http://pastebin.com/ppE6seaj
function nestDiv( parent, total ){

var element = $(“”).appendTo( parent );
var repeat = total – 1;
if( repeat > 0 ){
var i = 0;
for( i = 0; i < 10; i++ ){
nestDiv( element, repeat );
}
}
}

var test = {};
test.withoutCache = function(){
var i = 0;
for( i = 0; i < 1000; i++ ){
jQuery(".test").data('test', i );
}
}

test.withCache = function(){
var self = jQuery(".test");
var i = 0;
for( i = 0; i < 1000; i++ ){
self.data('test', i );
}
}

jQuery(document).ready( function(){
nestDiv( $('body'), 5 );
jQuery('div').eq(500).addClass('test');
});
Ok, this version creates 11,111 divs (arbitrarily), nesting them up to 5 deep in the hierarchy.
It then picks the 500th div (arbitrarily) and applies the class "test" to it.
test.withCache and test.withoutCache are then run.
Results using straight DOM querying via selector:
test.withCache();
Profile (109.735ms, 15011 calls)
test.withoutCache();
Profile (189.083ms, 25001 calls)
Ok so after that I decided to make it use the "this" context as the original article points out. http://pastebin.com/TPxxdPSV
Once again, 11,111 divs, but this time the javascript is as follows:
jQuery(document).ready( function(){
nestDiv( $('body'), 5 );
jQuery('div').eq(500).addClass('test');

jQuery('.test').bind('without_cache', function(){
var i = 0;
for( i = 0; i < 1000; i++ ){
jQuery(this).data('test', i );
}
});

jQuery('.test').bind('with_cache', function(){
var self = jQuery(this);
var i = 0;
for( i = 0; i < 1000; i++ ){
self.data('test', i );
}
});
});
Now I find these results interesting, due to a virtually negligible difference.
Results using "this" context variable:
var test = jQuery('.test');

test.trigger('with_cache')
Profile (100.184ms, 15067 calls)
test.trigger('without_cache')
Profile (108.723ms, 17065 calls)
Conclusion would be that the "this" context is not nearly as expensive as actually querying the DOM.

Gabriel, hiding or showing elements if Javascript is present should always be done whith css (explaination just after). I know what i’m talking about because if ever you will had a lot of js files in a project you will appreciate to get rid of all this $(selector).hide(); and $(selector).show() all over your javascript code. Trust on me, the best pratice for nearly all case of hiding element when Javascript is active is just to add one time a “js” (or whatever you whant for the name) on the body tag using Javascript and write your exceptions in the css.

For example, if you have a hidden alert box which is opening with javascript but is directly visible without :

<div class=”my-alert-box”>
<a href=”#”>Show the message</a>
<div>You should upgrade your account!</div>
</div>

.my-alert-box {
background: red;
color: red;
}
.my-alert-box a {
color: red;
font-weight: bold;
}

.js .my-alert-box a,
.my-alert-box.show div {
display: block;
}

.js .my-alert-box div,
.my-alert-box a {
display: none;
}

Here, you could show your box with js using .show(). Or show it using your CSS by adding the “show” class on it. It’s often usefull to have a class on the element regarding to his state (shown or hidden).
You can note that i have hidden the link when there is no Javascript, because the box is already shown !

I concentrate my js code on the fonctionnal part, not just dealing with graphic aspect all the time with many hide() and show() everywhere.

Trust me, i had to write big JS and i’m CSS expert and almost never use .css(). It’s usefull for dynamic coordinates often, but most of the time, changing colors, backgrounds, or so, should be done with CSS because it’s just graphic design.

Thank you for posting this article. While I’m glad so many folks are happy to write JavaScript with jQuery now because it makes it so easy, it also makes me cringe when I see these kinds of issues. With the risk of sounding cliché, I think it makes it _too_ easy and does not encourage people to learn what is actually going on under the hood.

I agree with the siblings() method exposed by Ravindran, and was thinking about it when reading the example code (to test if i found the error ;) )

I think that the algorithm of your second final example code is less readable because the filter() method makes us lost the flow of the code. It’s more complicated to read than siblings() because siblings() = “return all brothers” it’s simple and direct, filter() = “find all the element matching the selector”, it’s longer to think and to notice visualy (i know, the code don’t have to be visual, but sometimes it helps and it is not more expensive). Personnaly i was lost for seconds when reading this code.

It’s a ridiculous detail, but i think it’s less fluid using filter()…

Thanks for this article !

If I remember correctly, return false in a jQuery event handler is the same as calling preventDefault() and stopPropagation(). Usually, you don’t want to stop propagation (at least in my opinion).

Changing the order is not very usefull except in some case because this three actions will be executed in a millisecond… That’s why this example code is just an example code, it’s stupid to show a block, add a border, and hide it just after without delay…
Sorry but the first is definitely the best ;) and it’s more readable with indentation afterwards.