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

  1. Ext.DomHelper.append( myDiv, {
  2.    tag: 'div',
  3.    style: 'width:100%;border:1px solid blue;',
  4.    cls: 'testClass',
  5.    children: [{
  6.        tag: 'a',
  7.        href: 'http://www.google.com/',
  8.        children: [{
  9.            tag: 'span',
  10.            html: 'Google'
  11.        }]
  12.    }]
  13. } );

jQuery’s FlyDom:

javascript

  1. $( myDiv ).createAppend(
  2.    'div', { style: 'width:100%;border:1px solid blue;', class: 'testClass' }, [
  3.        'a', { href: 'http://www.google.com/' }, [
  4.            'span', {}, 'Google'
  5.        ]
  6.    ]
  7. );

This can be achieved in DOMDom, with comparable speed and code size with the following descriptor:

javascript

  1. DOMDom.append( { 'div[style="width:100%;border:1px solid
  2. blue",class="testClass"] a[href="http://www.google.com/"] span':
  3. '#Google' }, myDiv );

Currently works with YUI, but it will probably be ported to jQuery and other libraries.

Posted by Dion Almaer at 4:06 am
16 Comments

+++--
3.8 rating from 59 votes

16 Comments »

Comments feed TrackBack URI

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?

Comment by DeadCabbit — July 12, 2007

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?

Comment by Jerome — July 12, 2007

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 :)

Comment by Jerome — July 12, 2007

innerHTML is faster than standard dom anyday…
this is stupid, straight up. For all this hassle you might as well use innerHTML.

Comment by Joe — July 12, 2007

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.

Comment by gonchuki — July 12, 2007

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.

Comment by JDP — July 12, 2007

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.

Comment by Zach — July 12, 2007

I’ll use innerHTML any day, but if I had to choose from the above, I’d say jQuery’s version is more readable.

Comment by Scriptor — July 12, 2007

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.

Comment by cdude — July 12, 2007

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 :)

Comment by Jerome — July 12, 2007

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

Comment by carmen — July 12, 2007

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' }
}
});

Comment by Jack Slocum — July 12, 2007

@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.

Comment by Jerome — July 12, 2007

sorry, Jack wins!

Comment by Mike Kidder — July 12, 2007

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:

The most obvious conclusion of these tests is that innerHTML is faster than “real” W3C DOM methods in all browsers. The W3C DOM table methods are slow to very slow, especially in Explorer.

Comment by Andi — July 13, 2007

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;
};

Comment by Andi — July 15, 2007

Leave a comment

You must be logged in to post a comment.