What is better, appending new elements via DOM functions, or appending strings with HTML tags?

Question

I have seen a few different methods to add elements to the DOM. The most prevelent seem to be, for example, either

document.getElementById('foo').innerHTML ='<p>Here is a brand new paragraph!</p>';

or

newElement = document.createElement('p');
elementText = document.createTextNode('Here is a brand new parahraph!');
newElement.appendChild(elementText);
document.getElementById('foo').appendChild(newElement);

but I'm not sure of the advantages to doing either one. Is there a rule of thumb as to when one should be done over the other, or is one of these just flat out wrong?

Ponceau

Thanks, fixed. Too used to writing in jQuery. – Ponceau

innerHTML('<p>Here is a brand new paragraph!</p>'); should be innerHTML = '<p>Here is a brand new paragraph!</p>'; I think? – Excrescence

To the various answers here: innerHTML is certainly not faster. This is a false positive from older browsers (IE). document.createElement is now heavily optimized in many browsers. See: jsperf.com/dom-table-generation – Spinule

Also of interest is OWASP's "cheat sheet" for DOM code (which condemns innerHTML): owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet – Spinule

@MattMcDonald: while it's true that the quirksmode page is out of date, linking to a benchmark that creates 1000s of empty tables in a tight loop doesn't prove your point. innerHTML has the overhead of going through the parser, so it should be slower than a reasonable DOM1 implementation for trivial modifications. On the other hand, when building a complicated DOM, using createElement and friends requires many more JS<->C++ interaction than setting innerHTML. These calls still don't have zero overhead, unfortunately. It would be interesting to see real results on realistic workloads. – Burra

@MattMcDonald - I agree with Nickolay; that's not a very representative example. See this: jsperf.com/innerhtml-vs-w3c-dom – Stein

@lwburk ignoring the fact that your proposed example is something that should never be used in a production environment, you're selling the W3C DOM short. Please see my revision: jsperf.com/innerhtml-vs-w3c-dom/2 – Spinule

@MattMcDonald - Absolutely. Thanks for bringing document fragments into the discussion. – Stein

Answer 1

Some notes:

• Using innerHTML is faster in IE, but slower in chrome + firefox. Here's one benchmark showing this with a constantly varying set of <div>s + <p>s; here's a benchmark showing this for a constant, simple <table>.

• On the other hand, the DOM methods are the traditional standard -- innerHTML is standardized in HTML5 -- and allow you to retain references to the newly created elements, so that you can modify them later.

• Because innerHTML is fast (enough), concise, and easy to use, it's tempting to lean on it for every situation. But beware that using innerHTML detaches all existing DOM nodes from the document. Here's an example you can test on this page.

  First, let's create a function that lets us test whether a node is on the page:

  function contains(parent, descendant) {
      return Boolean(parent.compareDocumentPosition(descendant) & 16);
  }
  

  This will return true if parent contains descendant. Test it like this:

  var p = document.getElementById("portalLink")
  console.log(contains(document, p)); // true
  document.body.innerHTML += "<p>It's clobberin' time!</p>";
  console.log(contains(document, p)); // false
  p = document.getElementById("portalLink")
  console.log(contains(document, p)); // true
  

  This will print:

  true
  false
  true
  

  It may not look like our use of innerHTML should have affected our reference to the portalLink element, but it does. It needs to be retrieved again for proper use.

Stein

Excellent answer, but please rephrase the first claim (faster innerHTML) or provide a source. It's not clear to me which is actually faster and there's a link to a benchmark that shows that it's not always faster in modern browsers. See Matt McDonald's comment to the question. – Burra

@Burra - See my edit. innerHTML does seem to be considerably faster on a more complicated input. – Stein

Thanks for taking time to create a complicated enough example that confirms my suspicions! – Burra

@Burra The linked benchmark was buggy (causing the innerHTML version to replace the previous benchmark loops content, but the DOM version to create an ever-growing document) which made the DOM look slower than it is. After the fix, the innerHTML version is slower in FF and chrome, but still faster in IE11. – Mowbray

"But beware that using innerHTML detaches all existing DOM nodes from the document." This statement is incredibly misleading. The statement is only true if you use innerHTML on the document.body object. If you change the innerHTML of a div somewhere in the document, only DOM nodes in that div will be detached. – Decorum

Answer 2

There are a number of differences:

1. innerHTML has only been standardised by the W3C for HTML 5; even though it has been a de facto standard for some time now across all popular browsers, technically in HTML 4 it's a vendor extension that standards-adherent developers would never be caught dead using. On the other hand, it's much more convenient and practically it's supported by all browsers.
2. innerHTML replaces the current content of the element (it does not let you modify it). But again, you gain in convenience if you don't mind this limitation.
3. innerHTML has been measured to be much faster (admittedly, that test involves older versions browsers that are not widely used today).
4. innerHTML might represent a security risk (XSS) if it's set to a user-supplied value that has not been properly encoded (e.g. el.innerHTML = '<script>...').

Based on the above, it seems that a practical conclusion might be:

• If you don't mind the fact that innerHTML is a bit limiting (only total replacement of DOM sub-tree rooted at target element) and you don't risk a vulnerability through injecting user-supplied content, use that. Otherwise, go with DOM.

Telegraphy

Just a general comment, which is not directed at you but at point number 1. Makes me laugh every time I hear a developer say he will never break standards and in the second sentence that he needs to learn how to think outside of the box... – Dyaus

@ItayMoav: IMHO, someone who will "never" break standards has "never" worked with real-life clients and deadlines. But I also believe that it's a bit dangerous to link "thinking outside the box" with the "whatever, this seems to work" mentality that we see time and time again. – Telegraphy

this is where experience should kick in. To help us choose the right tool. Besides, such mentality makes sure I have plenty of work, and food on my plate :-D – Dyaus

innerHTML ;) capitalize HTML – Yepez

Answer 3

Though this is an old thread, one thing that is not mentioned is the while innerHTML can be faster, care should be taken. Using innerHTML will render every child of the modified element, old and new alike. As such, one single innerHTML assignment is faster (slightly) than DOM create/append, but multiple innerHTML will definetly be slower.

For example:

for(let i=0; i < 10; i++)
   document.body.innerHTML+='<div>some text</div>';

will be nearly nearly 5x slower than

let html = '';
for(let i=0; i < 10; i++)
   html += '<div>some text</div>';

document.body.innerHTML = html;

Since innerHTML assignment is letting the browser natively create/append elements, the second methods results in 10 elements being natively created/appended, while the firstmethod results in 55 elements being created/appended (and 45 being destroyed): 1 element created on first loop-iteration, 2 elements created on the second loop-iteration (the original being destroyed), 3 elements created on the third loop-iteration (the previous 2 being destroyed), and so on.

If you use innerHTML for speed, you must make sure to create the entire html string first before making the innerHTML assignment, such as creating fresh DOM containers/elements. innerHTML, on the other hand, is a performance loser when appending any container with existing childNodes, especially those with large number of childNodes.

Endocranium

This enabled about a 100x performance improvement in my particular use case, which started with an egregiously inefficient looping through "innerHTML +=" up to a couple of thousand times. Building all the new HTML into a single variable and then accessing the DOM only once completely eliminated the freeze-ups with only a nominal amount of change to the code. – Induplicate

Answer 4

According to this benchmark data, you will receive much faster results with innerHTML than creating DOM elements. It's especially clear when using older IE versions.

Hemoglobin

Answer 5

First one is straight forward, easier to read, less code and might be faster.
Second one gives you much more control over the element you create, i.e. makes it much easier to modify the new Element using JS (like attaching events, or, just use it in your code).
Second way is for "purist" who like "clean" code (no quick and dirty).
I say, use both, see what fits you better and go with it.

Dyaus

Answer 6

I always prefer readability unless the perf difference is extreme. In a one-off case of this, it probably will be a marginal difference.

In a one-off case like this, setting the innerHTML property will be easiest to read.

But if you are doing a lot of programmatic content generation in JavaScript, it is cleaner and easier to read and understand the DOM option.

Example:

Compare this innerHTML code:

http://jsfiddle.net/P8m3K/1/

// Takes input of a value between 1 and 26, inclusive,
// and converts it to the appropriate character
function alphaToChar(alpha)
{
    return String.fromCharCode('a'.charCodeAt() + alpha - 1);
}

var content = "<ul>";
for(i = 0; i < 10; ++i)
{
    content += "<li>";
    for(j = 1; j <= 26; ++j)
    {
        content += "<a href=\"" + alphaToChar(j) + ".html\">"
            + alphaToChar(j)
            + "</a>";
    }
    content += "</li>";
}
document.getElementById("foo").innerHTML = content;

To this DOM code:

http://jsfiddle.net/q6GB8/1/

// Takes input of a value between 1 and 26, inclusive,
// and converts it to the appropriate character
function alphaToChar(alpha)
{
    return String.fromCharCode('a'.charCodeAt() + alpha - 1);
}

var list = document.createElement("ul");
for(i = 0; i < 10; ++i)
{
    var item = document.createElement("li");
    for(j = 1; j <= 26; ++j)
    {
        var link = document.createElement("a");
        link.setAttribute("href", alphaToChar(j) + ".html");
        link.innerText = alphaToChar(j);
        item.appendChild(link);
    }
    list.appendChild(item);
}
document.getElementById("foo").appendChild(list);

At this level they start to become quite similar length wise.

But the DOM code will be easier to maintain, and you're a bit less likely to make a typo or mistake that is hard to diagnose, like omitting a closing tag. Either your elements will be in your document, or they won't.

• With more complicated scenarios (like building treed menus), you'll probably come out ahead with DOM code.
• With scenarios where you have to append multiple types of content together to build a document with more heterogeneous content, it becomes a slam dunk. You don't have to ensure you call your child append code before calling the parent append code.
• With scenarios where add, remove, or modify existing static content, DOM will usually win.

If you start doing complicated DOM modifications (one of the last things I mentioned), you'll definitely want to check out a library built around DOM modifications, like jQuery.

Excrescence

I know from your comment on the OP you've used jQuery. I just mentioned it for people who find your question in the future :) – Excrescence