Don't use .innerHTML ! Nost just for security, but also for convenience. Use document.createElement, and node.appendChild; this is much more powerful as you can abstract views and components into pure functions.
Example:
document.innerHTML = ''; .textContent = "";And it has the same end result.
Also, technically, this should be faster since that empty string is not put through the html parser (tho browsers might optimize for this special case already).
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.
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.