On XML DOM: Yes, you can insert nodes from XML into HTML. Obviously not all XML elements exist in XHTML, you would have to either write a parser/converter in Javascript, or use XSLT (a better choice, obviously). The cross-browser API is not consistent, but there is a way of doing it (natively) in almost every browser.

On Parsing HTML: It most likely has something to do with innerHTML being more like the initial document loading. You can read more on Steven Leviathan’s blog: When innerHTML isn’t Fast Enough and his solutions for quick rendering using a combination of DOM, innerHTML, and Regular Expressions.

You could say however that in the worst case, using the XML DOM is 22 times faster than the HTML DOM. Hey! ^_^

My personal way of doing things is to generate them from anonymous objects like this. Every elements is represented as a string (for textnodes) or an array (for normal nodes). The arrays can contain 3 types of data, namely a string for the tag, an object for properties and an array for childnodes. That way, I can sneak in any kind of data I want, not just strings, meaning that I get references instead of duplicates, bringing down overall memory usage. Also, since Javascript is a lot less forgiving than the HTML parser, I’m much less likely to run into code that “sort-of works”, but is actually broken because I’ve forgotten a bracket.

document.body.appendChild(JSON2HTML(
["div",{ className:"mainContent" },[
["h1",[ "JSON2HTML" ]],
["div",[ "This is just a very simple demo" ]],
["div",[
["ul",[
["li",{ style:{font-weight:"bold"} },[ "It's easy" ]],
["li",[ "It's beautiful" ]],
["li",[ "It works" ]],
]]
]],
]]
));

Also, when tweaking / changing / debugging the layout, an innerHTML approach typically provides a more direct / obvious path between what’s in your code and what’s in the browser.

Also, can we just drop the “correct” arguments? Both approaches are fully supported by the browser vendors – they are both valid.

…less than sign or ampersand to script insertion vulnerabilities). So knowing that when working with divs in HTML, the DOM is only up to about 5 times slower (not 35), is very useful information.

Also these tests show that the DOM itself is not inherently slow; the XML DOM performance shows otherwise. Apparantly however the browsers have tacked some other stuff onto the DOM methods which makes it slow, and there is definitely room for improvements. Actually, if you look at the test results on QuirksMode, you can see that between IE 5.5 and IE 6, Microsoft did something that made performance decrease dramatically.

@digitalIchi: Hmm, I would think it would be faster. I will keep it in mind if I’m doing more testing in the future.

@matanlurey: I agree completely :).

~Grauw

It’s a quick browser check that works for the two browsers that I tested here. Are you really going to base your opinion on that? I am providing the code fragments just to illustrate what changes I made to the original test.

Either way, as I wrote, originally I constructed an XML document and compared that with string building, and the performance differences were negligible, so the QuirksMode’s results made me wonder. I wrote down my findings. You can appreciate it if you wish, or not.

Personally, 50% of the time I am working with XML documents, so having some numbers to base my code practices on is very relevant to programming good applications. I am really convinced that string building is hard to manage, and that by using the DOM you can avoid a lot of bugs that would occur otherwise; with XML such bugs are especially harmful, but also in HTML it can result in nasty hard-to-find issues (ranging from missing parts after a

Like everything else complicated, it depends.

Great to hear, but this isn’t a rebuttal to the conventional wisdom — it’s a pedantic clarification at best.

JavaScript is not inherently slow; if you have used Spider Monkey (or better yet, Rhino) in a standalone or plugin environment it actually competes quite well with other interpreted languages. An example is Jaxer, the JavaScript http server.

The main reason for “slowness” is the browser – it’s security sandbox and of course, the DOM.

Obviously if you need to create a dynamic 50×50 table (and can’t use XML/XSLT for some design reason), the 50ms innerHTML method is a better choice than the 1000ms pure-DOM method. You can’t have a user waiting a second or more.

However, when creating only a handful of DOM elements (say even 5×5), the difference in speed is negligible (the user won’t notice a 10ms difference) – the opportunities/features/standards of DOM node creation is a better choice.