When do you use DOM-based Generation against using / innerHTML / JQuery strings to create DOM content?

Question

I was wondering when to use DOM-based generation compared to .innerHTML or adding strings using the JQuery.append method? I read the related post here Should you add HTML to the DOM using innerHTML or by creating new elements one at a time? but I am still not sure of the use for each method. Is it just a performance issue when I always chose one of them?

Let's say that the form is an arbitrary variable:

DOM Generation

var div = document.createElement("div"), label = document.createElement("label"), input = document.createElement("input"); div.appendChild(label); div.appendChild(input); form.appendChild(div); 

JQuery

  $(form).append("<div><label></label><input></input></div>") 

Answer 1

The second one is more readable, though from jQuery, which works innerHTML for you. In JS vanilla, it will be like this:

 form.insertAdjacentHTML("beforeend", "<div><label></label><input></input></div>"); 

... which, I think, beats even jQuery. Although, you should not worry about performance . Performance always depends on the number of nodes to insert - for single HTML parsers it will be slower than creating them directly, for large HTML strings its own parser is faster than a script. If you are really worried about performance, you will need to test, test, test (and I would say that something is wrong with your application).

However, there is a big difference between the two methods: In C # 1, you have three variables with links to DOM elements. If, for example, you would like to add an event listener to the input, you can do this immediately and do not need to call querySelector on the form , which would be much slower. Of course, when inserting there are really a lot of elements - using innerHTML - you would not need to do this at all, because you would use delegated events to really improve performance.

Note that you can also shorten method # 1 with jQuery in oneliner:

 var div, label, input; $(form).append(div=$("<div/>").append(input=$("<input/>"),label=$("<label/>"))); 

---

My conclusion:

• To create only a few elements, the DOM approach is cleaner.
• Basically, html lines are more readable.
• In standard situations, none of them works faster - test results vary.

Personally, I do not like (directly) innerHTML for several reasons, which are well described in these two and here . In addition, IE has an error in the tables (see Unable to set innerHTML to tbody in IE )

Answer 2

Generally speaking, repeatedly pressing the DOM is much slower than replacing a large HTML block with innerHTML. I believe that there are two reasons for this. One of them is reflow. The browser should redistribute the potential impact on a potentially large number of elements. The other, I suppose, and someone will correct me if I am mistaken, is that in translating things that happen in the browser after the compiled runtime, where the rendering and layout are done, it can be used in JavaScript. Since the DOM is often under constantly changing conditions, you have to start this process each time with little ability to cache the results of any kind, perhaps to some extent, even if you just create new elements without adding them (since you’re probably to want CSS preliminary procedures and things like browser “mode” due to doctype etc. that can be applied in general context in advance).

DOM methods allow you to create document fragments and create and add HTML elements to those that do not affect the actual layout of the document, which helps to avoid unnecessary recalculation.

But here where it is strange.

• Inserting new HTML in a node without anything in it - next to a tie or something innerHTML, is usually much faster in many (mostly older) browsers

• Replacing a ton of HTML content is actually what DOM methods tend to win when performance is not too close to the call.

Basically, innerHTML, if it stinks, tends to stink of the rupture process where large swaps occur. DOM methods are better at break, but tend to create new HTML more slowly and inject directly without replacing anything when there is any significant difference whatsoever.

In fact, there are hybrid methods that can do quite interesting things for performance when you have such a need. I used one year ago and was impressed by the improved response time for sharing large snippets of HTML content for a lazy loading grid instead of just using innerHTML. I'm sorry that I can’t find a link to a guy who deserves praise for understanding this and describing it on the Internet (the author wrote a lot of RegEx materials too - couldn't google for me).

Regarding the vs perf style, I think you should avoid frequently changing the structure of the DOM node, but constructing the HTML in the document fragment in advance and using innerHTML is largely dependent on the judgment. I personally like innerHTML for the most part because JS has a lot of powerful string methods that can quickly convert data to HTML-ready strings. For instance:

 var htmlStr = '<ul><li>' + arrayOfNames.join('</li><li>') + '</li></ul>'; 

This single line UL I can assign directly to innerHTML. It is almost as easy to assemble complete tables with the correct data structure and simple while loop. Now go to the same UL with as many LIs as the length of arrayOfNames with the DOM API. I really can't come up with a lot of good reasons to do this for myself. innerHTML became a de facto standard for some reason before it was finally adopted in the HTML 5 specification. This may not be consistent with the node-based object setting of the htmlElement API DOM object, but it is very efficient and helps you keep the code concise and legible. However, I would not do this, it is to use innerHTML to edit and replace existing content. It is much safer to work with data, build and share in the new HTML, than refer to the old HTML, and then start parsing innerHTML strings for attributes, etc. When you have DOM manipulation methods that are convenient and ready for this.

Your main performance problem should probably be to avoid hitting the “live” parts of the DOM, but otherwise I would leave people to type and test where the HTML is expressed. However, innerHTML exists and has been working in the HTML5 working draft for many years, and it is pretty consistent in modern browsers. It was also de facto for many years before, and was perfectly viable as an option, since before Chrome became new, IMO, but this is a debate that was mainly done at this point.

Answer 3

This is just a performance issue. Choose the one that suits you best.

jsPerf is full of performance tests like this: test