Thursday, July 12th, 2007
DOMDom: More DOM, Less DOM
Category: CSS
, JavaScript, Library
Zach Leatherman has created another DOM creation class, DOMDom, (with support for HTML Fragments) that uses
the CSS query language. But instead of using the language to query nodes, it is used to create nodes.
To make <div style="width:100%;border:1px solid blue" class="testClass"><a href="http://www.google.com/"><span>Google</span></a></div>, you'd have to do the following in other packages:
DomHelper:
JAVASCRIPT:
-
-
Ext.DomHelper.append( myDiv, {
-
tag: 'div',
-
style: 'width:100%;border:1px solid blue;',
-
cls: 'testClass',
-
children: [{
-
tag: 'a',
-
href: 'http://www.google.com/',
-
children: [{
-
tag: 'span',
-
html: 'Google'
-
}]
-
}]
-
} );
-
jQuery's FlyDom:
JAVASCRIPT:
-
-
$( myDiv ).createAppend(
-
'div', { style: 'width:100%;border:1px solid blue;', class: 'testClass' }, [
-
'a', { href: 'http://www.google.com/' }, [
-
'span', {}, 'Google'
-
]
-
]
-
);
-
This can be achieved in DOMDom, with comparable speed and code size with the following descriptor:
JAVASCRIPT:
-
-
DOMDom.append( { 'div[style="width:100%;border:1px solid
-
blue",class="testClass"] a[href="http://www.google.com/"] span':
-
'#Google' }, myDiv );
-
Currently works with YUI, but it will probably be ported to jQuery and other libraries.
3.9 rating from 54 votes
Domhelper is pretty readable, but why not pass an html string and parse it? Actually innerHTML injects are pretty slow in IE, but apart form that I do not find it *that* dirty… do I miss something here?
So the argument is that innerHTML isn’t a W3C standard, but if all the browsers you care about support it, why is that a problem? For me, PPK’s test results say it all when it comes to deciding whether to use convoluted parsing and object creation vs innerHTML.
http://www.quirksmode.org/dom/innerhtml.html
Why reinvent the wheel and make it square, unlesss you’re driven by standards OCD?
Erm, sorry for sounding horribly strident. I’ve just finished my third cup of coffee and I’m feeling a bit wired.
Still, FWIW I stand by the logic of what I said, if not the tone :)
innerHTML is faster than standard dom anyday…
this is stupid, straight up. For all this hassle you might as well use innerHTML.
innerHTML will be faster *until* browser developers give proper optimization to the DOM functions… it’s nonsense that directly creating the nodes is actually slower than giving potential tag soup that must be parsed and checked for sanity *before* creating the corresponding nodes.
Experimentation is good, but this seems to be too far afield from setting attributes programmatically (like Ext), and equally far afield from the ease of using innerHTML. Not really a niche that needs to be filled.
DOMDom uses innerHTML by default, and can be switched over to DOM methods with the switch of a boolean.
It sounds like the argument being made here is that no one should use a DOM creation class at all, and we should just be sticking with raw innerHTML all the time. That’s fine by me, if you prefer it.
But the entire point of this class is to give you the option to use a shorthand method that most of us already know with the CSS query syntax already in most libraries today.
I’ll use innerHTML any day, but if I had to choose from the above, I’d say jQuery’s version is more readable.
The examples should show the attaching of event handlers to the dom nodes as they’re built. That would be more usefull and should shut the innerHTML whiners up. I don’t know about you guys but when I’m adding elements dynamically to the DOM, i’m usually gonna need to attach some event handlers. Plus, no string concatenation everywhere with innerHTML. Sounds to me like the innerHTML supporters are people that would get a chunk of HTML from an “ajax” request and just throw it in some container div.
I appreciate the structure it provides but I can’t get over the terrible inefficiency. I say potato, you say an edible starchy tuber of the nightshade family.
Ooh, and string concatenation can be quite nice with a C# style StringBuilder function based on array push and join.
And another thing, blah blah blah…
There’s just no shutting up us whiners :)
wheres the inefficiency? i havent tried this one, but DOM creation is plenty fast here with jquery/firefox and a 10 line dom+events-creation plugin..
well if 90 ms is fast. id like to see more DOM creation benchmarking - now that selector-speed has been done to death
That’s the “verbose” DomHelper syntax. It could be shortened to:
Ext.DomHelper.append( myDiv, {style: 'width:100%;border:1px solid blue;',
cls: 'testClass',
cn: {tag: 'a', href: 'http://www.google.com/',
cn: {tag: 'span', html: 'Google' }
}
});
@Carmen: “id like to see more DOM creation benchmarking”
It would be good to see more benchmarks but I trust the quirksmode results enough to think that other tests aren’t going to produce results that are significantly different. Or at least not different enough in IE (who doesn’t love Firefox but there’s no getting away from the fact that it’s dominant) to make DOM object creation viable, if you care about speed of execution.
I dunno, maybe I’ve got optimisation OCD. I’ll shut up now, I promise.
sorry, Jack wins!
The syntax of DOMdom doesn’t look very logically, jQuerys DOM builder looks the best.
I personally prefer innerHTML - PPK’s test case shows why. I think it’s quicker because internal DOM building on very low level is used implicitly to build the DOM instead of explicit JavaScript methods. If your code MAY not be valid simply use try .. catch.
Quote from http://www.quirksmode.org/dom/innerhtml.html:
PS: Prototype still has no DOM builder, has it? So what about:
$C = function(string) {
var D = document.createElement(’div’);
try { D.innerHTML = string; } catch(e) {}
if (D.hasChildNodes())
return D.childNodes.length == 1 ? D.firstChild : D.childNodes;
return null;
};