What is the best way to traverse the DOM?

When you try to get an element is it better to do something like this:

var element = $('#someDivisionId .container-example .other-example').find('div');

or is it better to assign an id to that element when you are creating it and find it like this:

var element = $('#elementId');

By better I mean which way is faster and which way is a better practice?


Also in this line of thought why would you do:

$('#someDivisionId .container-example .other-example div').each(function(){});

when you can get to the same divisions by just doing:

$('#someDivisionId .other-example div').each(function(){});

I have seen this in people's code and I was wondering if it somehow speeds up the traversal of the DOM. Why would anyone do this?

 

Well, first up that's not traversing the DOM, at least not on your part -- jQ might be doing that for you, but really that's not what YOU are doing. Likewise 'speed' and 'efficiency' went out the window when you chose to use jQuery, so sweating that is pretty pointless.

That said, using a single ID selector is fine if you only want to target one element at a time. This:
var element = $('#elementId');

should only EVER return ONE element... since ID's are UNIQUE and should exist only ONCE in your markup. That's why/when you use it.

This:
var element = $('#someDivisionId .container-example .other-example').find('div');

would return a list of all DIV with those parent selectors instead of just one item.

As to why you'd do those latter queries, what if you have .other-example OUTSIDE .container-example as well? If you had this markup:

<div id="someDivisionId">
	<div class="otherExample">Test 1</div>
	<div class="containerExample">
		<div class="otherExample">Test 2</div>
		<div class="otherExample">Test 3</div>
	</div>
	<div class="otherExample">Test 4</div>
</div>
<div class="otherExample">Test 5</div>

Code (markup):

$('#someDivisionId .otherExample') would return all four .otherExample inside #someDivisionID, but not the last one since it's outside that.

$('#someDivisionId .containerExample .otherExample') would return only the two inside it. (test 2 and test 3) since that's exactly what the selector list says. IF the markup is built using the same classes in different places and you remove that middle selector, you might get more than you bargained for.

Though honestly I wrote markup with that many classes/ID's in one section I'd put a bullet in my head...

In any of those scenarios ALL of those are slow -- but that's jQ for you, pupu for two.

 

Oh, and as to ACTUALLY walking the DOM, that would go something like this:

function walkChildren(parent, functionHandler) {
	var e = parent.firstChild;
	while (e) {
		functionHandler(e);
		e = e.firstChild || e.nextSibling || (
			e.parentNode == parent ? null : e.parentNode.nextSibling
		);
	}
}

Code (markup):

Which would ACTUALLY walk through in order all children of the element you pass as 'parent' -- that's "Traversing" or "Walking" the DOM.

In mother Russia... the DOM walks you...

 

thank you for the detailed response!

I can argue about speed and efficiency going out the window when it comes to jQuery, though. The front end of the application I am developing so far seems to work quick enough. Even though there might be several actions firing at once on a single click the response is instantaneous as it should be. And if I had to achieve the same functionality using pure JavaScript I would have to write ten times more code and had to consider a bunch of browser incompatibilities. So in my experience jQuery is not that bad at all. So I don't know why you would say it is slow. And what do you think is a quicker alternative?

 

Really hinges on what you are doing... in your case:

You're working on a web crapplet instead of an actual website from the sounds of it, which operates by slightly different rules -- even so I don't like web crapplication nonsense because in a lot of cases it's pissing away the usefulness, speed and functionality of perfectly good working sites. See what all the ajax-tard and script-tard BS has done to webmail; seven or eight years ago webmail had me predicting the death of mail clients -- today trying to use any of them sends me running and screaming back to mail clients with their buggy broken scripted asshattery that is ten times slower and consumes more bandwidth than if they just *SHOCK* used pageloads... all in the name of 'saving bandwidth' and 'making it faster' -- what a crock!

TEN TIMES? That would make me think you have broken methodologies and/or are overthinking whatever it is you're doing.

IMHO 90%+ of jQuery's codebase belongs in the trash as 90%+ of what it's used for by developers falls into three categories:

1) things that could be written smaller/faster with LESS code by simply using flat scripting. No joke on that -- mostly this is due to people failing to grasp how JS works in the first place as they failed to learn enough JS before diving into the fat bloated idiotic 'libraries'.

2) Things that are CSS' job and have no damned business in the scripting. (see most of the stupid animooted nonsense that amounts to 'designers' walking through a pile and tracking it all over a website's carpets.)

3) Crap that has NO MALFING BUSINESS on websites in the first blasted place. Typical examples include replacing functionality with no scripting off fallbacks, using JS to control layout, and of course AJAX loading static content.

It introduces 100k of scripting overhead which has to be parsed on every load, (I'm talking runtime, not bandwidth on that)... simple commands like $('#test') are ten to fifteen times slower than getElementById because of all the extra function calls and wrapping overhead. ".each()" introduces function calls (and therein stack manipulation) inside a loop quadrupling or MORE how long looping through elements takes over a simple FOR loop, etc, etc...

... and that's without talking about the complete idiotic waste of bandwidth most sites using jQuery have; endless pointless "scripting for NOTHING" garbage that reeks of people who never learned the golden rule of script writing -- if you can't make the page work without scripting FIRST, you have no business adding scripting to it.

By itself - zgip compressed - jQuery is almost HALF the size in bytes I allow for an entire page template not counting content UNCOMPRESSED; That's HTML+CSS+SCRIPTS+IMAGES in a page template. Uncompressed it is two thirds the upper limit I generally have for an entire page with content!

Needless to say when I see hundreds or even thousands of K of scripting on websites that are a content and usability equivalent of a Dr. Seuss book, with zero accessibility and zero graceful degredation... Not a happy camper.

Don't use scripting if you don't have to, Don't use scripting to do markup/pageload/css' jobs, use small custom libraries if you have operations you are doing a lot (like class swaps, which 'real world' should be what half the scripting people sleaze out should be doing instead), etc, etc...

jQuery is bloated, slow, inaccessible, pointlessly and needlessly cryptic, and worst of all most of what people do with it supplants functionality breaking accessibility. It is just as broken a asshat mess of crap as HTML 5, WYSIWYGS, or dicking around drawing goofy drawings in Photoshop before you even have semantic markup with a working semi-fluid elastic responsive layout, and then having the giant brass monkey balls to call oneself a 'designer'.

Shame all these broken sleazy shortcuts and halfwit practices are now not just the norm, but thrown around as sick buzzwords by people who don't know the first thing about HTML, CSS, or accessibility.

 

you have some good points and your opinion is much appreciated but tell me which version would you prefer as a programmer:

- JavaScript only - document.getElementById("someElementId").getElementsByTagName("div").setAttribute("class", "className");

or

- jQuery - $("someElementId").find("div").addClass("className");

You can see that the JavaScript code is almost twice as long and that is just for the simplest of all things. When you consider more complicated operations and built in functions and the biggest of all headaches BROWSER COMPATIBILITY you might as well throw in the towel and say "I love jQuery". Those 100k of scripting overhead is nothing to the 100 hours of working overhead you are going to spend to do the same thing in pure JavaScript. You are right, it might work faster, but is it worth sitting and rewriting already existing libraries and reinventing the wheel to gain that speed? In the end of the day you may end up a really good JavaScript programmer whose application work slightly faster but are not going to be a very productive one.

 

Actually, that's an excellent example of using scripting to do CSS' job... since I'd just add a class to 'someElementId' and then target it's child DIV... or I'd have this:

#someElementId div {}

In the CSS in the first blasted place. Remember, if all your child elements are getting the same class, none of them need classes. That treads into being the same type of halfwit BS as what turdpress calls a menu.

... and I still don't get what the blazes jQ has to do with 'browser compatibility' apart from people CLAIMING it does; at most that's like 1% it's codebase MAYBE; and generally speaking just means broken thinking and/or methodology if it's THAT big an issue.

 

Well... yes, and no. You can't have CSS based on selections / states, given a #someElementID div {} - if that state is just used sometimes, doing it in pure CSS is gonna be a problem. Of course, however, you could do it with a littlebit of javascript or jQuery AND CSS, by simply doing #someElementID.someclass div {} and then do
$("#someElementID").addClass('someclass'); or
document.getElementById('someElementID').setAttribute('class','someclass');

Not much difference in the jQuery vs. javascript length of code, really...

 

Hence the word "or"... as what you used for examples is EXACTLY what I meant in the first case where I said "add a class to 'someElementId'".

Even less difference if you're already in an anonymous function where you pass document as a parameter like "d"... though in both cases setAttribute would corrupt any existing classes, so you would/should have a function set up to handle that bringing it up in code size, but that's the type of thing you'd do often enough to BELONG in a library (like jQ) as opposed to all the pointless crap that's in jQ like EVERYTHING in "effects", show/hide/toggle, separate functions for events, pointlessly idiotic code bloat like .val, idiotic redundancies like separate event handlers when they have .on -- meaning they need .trigger to make up for overwriting existing element attributes like .blur and .focus,, etc, etc..

Even just passing selectors to .find is wasted/stupid coding... Seriously, in the example isn't the "find" kinda silly since this:
$('#someElementID div')

Should be functionally identical to
$("someElementId").find("div")

Or am I missing something on how jQ works?!? I can understand something like .find for a user callback or object matching, but not for selectors.

Of course, that I HATE seeing logic crammed onto one massive single line means it's method of 'helpers' isn't real high up on my code legibility scale either... same reason I hate every time I see CSS attribute/value pairs crammed onto single lines too. We have a ENTER key and tabs, יהוה forbid we use them... We're not entering code into BASIC one line program contests from the '80s or the IOCCC!

There ARE useful bits -- the class functions (which now exist in modern browsers under classList), event wrapping with .on (one of the few ACTUAL cases of fixing browser compatibility), unifying/shim for load/ready -- but the penalty of all the extra crap makes it impossible to find the forest for the trees, AND by it's very nature it promotes the use of cryptic code with filled with bad practices.

Bad practices like EVERYONE and their brother calling selectors when they should actually be walking the DOM on anything complex or many event based things.

 

Not completely identical.
$("#someElementID div") will match div's directly under the $("#someElementID"), while $("#someElementID").find('div') will match all div's contained within the ID - regardless of level.
Normally, you'd use find() to get to an element which isn't readily available as a standard CSS-selector sequence (at least that's how I use it, if need be). For instance, instead of targeting a specific tag or class several levels down, like this: $("#someElementID div div p span") you can do $("#someElementID").find('span') (or the same with a class) and then achieve the same thing. Whichever is the fastest, I'm not entirely sure, I haven't tested.

 

Uhm, I thought jquery supported the child selector ">" -- which does what you described. If not, what the devil is that for then? The CSS style selectors don't work like CSS?!? That seems... really stupid.

http://api.jquery.com/child-selector/

I mean, if just a space behaves like a child selector, why the hell does it have a child selector (NOT that it's a valid CSS style selector with the spaces around it... but that's just another strike against jQ). I think you're wrong on that one.