Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

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?

like image 681
Chris Sobolewski Avatar asked Dec 11 '11 03:12

Chris Sobolewski


People also ask

Why should you create DOM elements instead of using innerHTML?

#1) createElement is more performant Therefore, it is less efficient than creating a new element and appending to the div. In other words, creating a new element and appending it to the DOM tree provides better performance than the innerHTML .

Should I use append or appendChild?

Difference between appendChild() and append()append() also allows you to append DOMString objects, and it has no return value. Further, parentNode. appendchild() allows you to append only one node, while parentNode. append() supports multiple arguments - so you can append several nodes and strings.

Which method is used to add components or elements to the DOM?

AppendChild. The simplest, most well-known method of appending an element to the DOM is certainly the appendChild() .

Which function in DOM allows you to create a new element?

The createElement() method creates an element node.


2 Answers

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.

like image 130
Wayne Avatar answered Nov 10 '22 23:11

Wayne


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.
like image 37
Jon Avatar answered Nov 10 '22 23:11

Jon