Javascript crazy idea finding a node

Question

I had a crazy (but so crazy that it just might work) idea where every element on a page is created in javascript but given an ID which is a hash of its path in the DOM.

So instead of searching through the DOM to find an element, you hash the path and then getElementById() with that hash.

Problem with this is getting the path might be more expensive than searching the DOM in the first place. Any ideas how this could be done or if it is just plain stupid?

Answer 1

I guess the question is what kind of problem you're trying to solve with that.

Hashing the path to get the element via a unique id is nice, but where do you get the path from? These will be pretty long "ids" and rather unwieldy. Or if you use hardcoded, hashed ids, you're greatly obfuscating your own code. And if you just slightly restructure the document, every path and therefore every id will change. And writing the whole site in Javascript sounds pretty insane, actually. :)

Overall it doesn't sound like it's worth the hassle. In any modern JS framework element lookup using CSS style selectors is usually not a bottleneck, but it's much easier to develop for. That may be different if you're writing raw JS, but then I'd argue that you shouldn't do that anyway, unless you have a masochistic streak. ;)

Answer 2

"Where every element on a page is created in javascript"

There's your problem. Now you are completely creating a page on the fly on the client's PC instead of serving up an already created page. They'll have to do that for every page. Something tells me this will negate any positive effects of your lookup by hash idea.

Answer 3

Sounds like you are reinventing a javascript framework like jQuery.

You could insert html fragments into the DOM and keep those references as function pointers, or simply assign each element a unique id as you insert them, and them requery the id later (which is very fast).

Answer 4

I see two major problems with this:

• As the page is created dynamically on the client side, search engine robots will just get an empty page.

• If there is any other script in the page changing the DOM, the paths to elements changes and the hashing doesn't work any more.

Answer 5

If you know the full path of the element, is going to that path actually hard enough to justify this sort of thing? Usually it's things like collecting elements by common aspects unrelated to their absolute path that's a hassle. And with engines like Sizzle out there, I'm not sure I'm seeing the use-case for this. :-)

I also wonder how you would handle it when moving elements around. Re-assign their hashes, presumably, which starts getting ugly fast.

Note that your approach doesn't only work with elements created at runtime by Javascript; you can assign them after the fact easily enough with a recursive descent function:

function createIDs(element) {
    var child;

    if (!element.id) {
        element.id = createElementID(element);
    }
    for (child = element.firstChild; child; child = child.nextSibling) {
        if (child.nodeType == 1) { // Element
            createIDs(child);
        }
    }
}

// Kick things off
createIDs(document.body);

That's a one-time hit on pre-generated content, rather than always having to re-generate content. Not advocating, just pointing out.