That depends. This conversation is not so relevant now because JavaScript is fast and the DOM is almost assembly code speed. When you slow things down, such a

That depends. This conversation is not so relevant now because JavaScript is fast and the DOM is almost assembly code speed. When you slow things down, such as using really old hardware or rewinding the clock to 12 years ago, things were much slower and the performance differences were readily noticeable. When the environment is slow the ultimate bottleneck for the DOM is the document object. This is the only entry and exit point to the webpage and with JavaScript being single threaded you can only execute one instruction at a time. To make things confusing though DOM instructions without JavaScript are executed much faster than JavaScript instructions, but DOM instructions from JavaScript are slower than JavaScript. This confusing because every time you exit the language, this applies to any language, to perform some external operation there is a small programming overhead that takes time. Such an external operation includes any DOM operation including .innerHTML. None of that had any bearing on visual page render, which had its own performance perils. Because of that it was/is faster to use the standard DOM methods, createElement or appendChild, when you had to execute those instructions only a few times for a given piece of logic. This because .innerHTML does a couple of things: removes existing DOM nodes (if any), parses a string, and inserts new DOM nodes. That normally applies to inserting a paragraph, changing an attribute, or some other singular piece of content. When the thing to change/insert comprises many DOM nodes, such as a table, it was dramatically faster to use the .innerHTML method, because then most of the work occurs outside of JavaScript. Keep in mind there is overhead for each any every instruction that leaves the language and .innerHTML method leaves the language only once. Also keep in mind the page DOM is bottlenecked to the document object so these instructions leaving the DOM could only do so one at a time in order. That overhead per language exit adds up and scales slower than the slower performance of .innerHTML, especially since the .innerHTML work occurred as native code in a faster language. There were compromised solutions, such as using document fragments. Almost nobody did this though. A document fragment allowed constructing a DOM artifact without touching the document object and so there was no bottleneck until inserting that artifact into the page. This was the fastest way to construct large complex things, but it imposed a lot of work on the developer, it wasn't widely supported (even though it was standard), and the API was less clear/familiar.