3 ms·

innerHTML might be faster (was true a few years ago).

austincheney 7y ago
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.
rndgermandude 7y ago
It might be/might have been faster, but it's also a massive footgun.
acdha 7y ago
That hasn't been true for many years — see e.g. https://segdeha.com/experiments/innerhtml/ https://segdeha.com/experiments/innerhtml/ for the Firefox 3 / Safari 4 era — and when it was, it was only in the case where you were blasting out huge amounts of changes at a time. For anything less than a complete rewrite of a large DOM hierarchy it was almost always faster just to update the elements in question using the DOM. As an example, there was a lot of cargo cult performance discussion around React in the first few years. A coworker was really excited about it but the first time we did a benchmark for code which updated a report table, React was 5 orders of magnitude slower because it used innerHTML instead of the DOM and even with keyed updates that was doing tons of extra work.
rasz 7y ago
Wouldnt worry about that. No matter which method you use its the actual DOM part showing the result that is slow. I have a thing that builds >4K row HTML table from localstorage data one line at a time, it takes 200-300ms to build (timed with performance.now()) depending on if I cloneNode/appendChild/build a string and shove it into innerHTML, but then about 2 seconds for the browser to actually update the DOM and show user the actual Table.

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.

rndgermandude 7y ago

It might be/might have been faster, but it's also a massive footgun.

acdha 7y ago

That hasn't been true for many years — see e.g. https://segdeha.com/experiments/innerhtml/ https://segdeha.com/experiments/innerhtml/ for the Firefox 3 / Safari 4 era — and when it was, it was only in the case where you were blasting out huge amounts of changes at a time. For anything less than a complete rewrite of a large DOM hierarchy it was almost always faster just to update the elements in question using the DOM. As an example, there was a lot of cargo cult performance discussion around React in the first few years. A coworker was really excited about it but the first time we did a benchmark for code which updated a report table, React was 5 orders of magnitude slower because it used innerHTML instead of the DOM and even with keyed updates that was doing tons of extra work.

rasz 7y ago

Wouldnt worry about that. No matter which method you use its the actual DOM part showing the result that is slow. I have a thing that builds >4K row HTML table from localstorage data one line at a time, it takes 200-300ms to build (timed with performance.now()) depending on if I cloneNode/appendChild/build a string and shove it into innerHTML, but then about 2 seconds for the browser to actually update the DOM and show user the actual Table.