4

When generating dynamic content, which way is better to simply create the HTML and insert it into a .innerHTML or to create elements in the DOM directly?

I'm not concerned with complexity or other. Just processing time on the client.

Which is quicker?

If I had to guess in order of efficiency (low processing time) this would be:

  1. DOM Creation
  2. .innerHTML property insertion
  3. direct writing

This would be inversely related to the complexity of implmenting:

  1. direct writing
  2. .innerHTML property insertion
  3. DOM Creation

This is a validatin question? Can someone validate that this is the trade-offs for determining how to update the client (i.e. javascript) when considering complexity and speed?

Research:

I'm not concerned with security like they are here-> InnerHTML vs. DOM - Security

InnerHTML vs. DOM This is not a duplicate as it covers only part of my question.

Community
  • 1
  • 1
  • I can't back this up with a link right now, but IIRC `innerHTML` is fastest. – Jon Jan 09 '12 at 22:35
  • 1
    possible duplicate of [What is better, appending new elements via DOM functions, or appending strings with HTML tags?](http://stackoverflow.com/questions/8461851/what-is-better-appending-new-elements-via-dom-functions-or-appending-strings-w) – Wayne Jan 09 '12 at 22:35
  • The dup I linked includes lots of jsperf links and a discussion around which is faster in which cases. – Wayne Jan 09 '12 at 22:36
  • Why is noboby comparing .innerHTML to say a direct write..say document.write() or simply rendering HTML directly? –  Jan 09 '12 at 23:28

4 Answers4

3

In my experience they are basically comparable in performance. However if you use the DOM approach you get better accessibility to the power of closures so you can bind data and functions to the individual DOM elements directly.

For performance, the main thing, regardless of approach, is to hide or remove the part of the DOM you want to modified, make all you alterations outside the DOM, then put it back into the DOM as one single operation to avoid unnecessary reflows (repaints) in the browser.

b-h-
  • 2,651
  • 1
  • 18
  • 9
2

It is not necessarily true that DOM insertion is faster than updating innerHTML, see benchmarks at http://segdeha.com/experiments/innerhtml/ and http://www.quirksmode.org/dom/innerhtml.html, for example. Implementing the innerHTML solution might be quicker, just note that it is not available when using XHTML.

Jan Pöschko
  • 5,412
  • 1
  • 28
  • 28
  • I'm using this and .innerHTML in my javascript...what error/warning should I see? Are you sure? –  Jan 09 '12 at 23:12
  • Do you serve your document as XHTML, i.e. as application/xhtml+xml? – Jan Pöschko Jan 09 '12 at 23:15
  • Actually, some browsers might already support `innerHTML` even in XHTML documents, and things should get better with `innerHTML` being part of the HTML5 standard: http://www.w3.org/TR/2008/WD-html5-20080610/dom.html#innerhtml1 – Jan Pöschko Jan 09 '12 at 23:21
2

From my own personal tests they're all fast enough for most needs. But if you're doing something crazy like creating thousands of elements to a page the fastest way is to use document fragments. John Resig wrote a good blog post about it. http://ejohn.org/blog/dom-documentfragments/

hobberwickey
  • 6,118
  • 4
  • 28
  • 29
1

Lots of jsPerf benchmarks cover this topic; try searching the web for "jsperf innerhtml domelement" or other meaningful combinations of your search.

maerics
  • 151,642
  • 46
  • 269
  • 291