1) innerHTML is faster than DOM "createElement" methods. Really. Potentially Wicked Fast(tm) in comparison.

2) Use of innerHTML is recommended if your need is one way. That is, you are just presenting content, after which you are "done." However, if you need to refer/traverse a DOM branch that you are changing, then you should use "createElement" DOM methods.

In summary, which to use? Answer: both. It depends on your case.

Oh, great. Now innerHTML will be forever personified in my mind as a smirking, raven-haired seductress in a dress cut down to here and slit up to there, throwing herself at me despite my best efforts to walk the straight and narrow of semantically correct code.

Maybe I just need to get out more.

I am a beginner and innerHTML is a good way for me to get results without having to deal with 20 lines of DOM work that twists my brain to pieces.

If anyone knows a way to simply get MySQL data into a page and resort/ re-query without refreshing the page without using innerHTML, drop me a line!

@Shaun: Nah. More talk, less development. It gives us something to ponder.

Me? I’m quite comfy up here on my fence, thank you very much.

As for innerHTML… I always feel dirty when I use it, so I don’t use it often. I’m a casual user. Just when I’m by myself and know it’s not hurting anyone but me.

I’d also like a pony.

So if I’m populating a page with data via ajax, which is easier to maintain? 1. A page that delivers XML, followed by many (many) lines of javascript removing DOM elements, creating DOM elements, appending elements etc. Or, 2. A page that delivers HTML, followed by one line of javascript that inserts it in the page.

Option 2 is infinitely easier to maintain (especially across developers). I’ve thought about this and written about it (http://www.agavegroup.com/?p=43) and just can’t get away from the simplicity of innerHTML (and the fact that it works 100% of the time…)

A typical example is inserting an entry from an RSS feed into an HTML page. The vast majority of feeds use CDATA or entity escaped markup for the content - that’s just a text string on HTML markup. What can be done other than innerHTML it right into the current node?

I’m toying with the idea of pushing the markup through a DOM Parser and get an HTML tree - but its not as well documented as XmlHttpRequest.

But then what happens if the stringified markup is invalid?

This is a trade off between the purity of unobtrusive javascript, and the spirit of DOM updates, and the practical problems out there on the web.

Unfortunately, most of the HTML out there is basically a text string. But then Internet Explorer has been dealing with that problem for years.

http://www.mochikit.com/doc/html/MochiKit/DOM.html#creating-dom-element-trees

I’m with Jonathan. If it’s widely supported, has proven to be faster (http://www.quirksmode.org/dom/innerhtml.html), why should we not use it?

It’s funny how discussion about innerHTML is starting around the web at the moment, and i bet it’s due to the AHAH microformat. Someone asked me about the browser support of this property when i posted a link to AHAH. Funny. :)

Just because the DOM2 methods are more structured doesn’t mean that there isn’t room for a quicker and easier approach to content/element insertion. I hear the same argument about HTML vs XHTML. “Because people can screw up HTML, we should force everybody to use XHTML.” Next you’ll hear people say that JavaScript shouldn’t be used because it’s dynamically typed.

I don’t know about you guys but I’d rather save myself the time of having to code 20 lines of createElement/appendChild’s when a single innerHTML will suffice.

Just do not go there, write some JavaScript helper functions and do it the right way.

I’m fairly disappointed with Firefox for adding support for it. People should just learn to use the much more structured DOM2 methods. However, it is good that Firefox’s implementation for XML documents will fail if it’s not well formed, unlike Opera.