[chrismorgan]

You know what’s slower than setting innerHTML? Doing just what setting innerHTML would have done, but bit by bit.

If you’re changing from one thing to another very similar thing, then doing precise edits makes sense. But if you’re changing structure significantly, then doing precise edits will be slower than just clobbering it all by setting innerHTML.

[eyelidlessness]

> You know what’s slower than setting innerHTML? Doing just what setting innerHTML would have done, but bit by bit.

This used to be conventional wisdom, but it’s less true today. Think of what innerHTML does:

1. Parse HTML

2. Create a document fragment or similar detached DOM root

3. Build the resulting DOM subtree

4. Append the subtree, potentially replacing an existing one

Skipping step 1 is potentially faster, sometimes significantly. It really only depends on how efficient your manual construction is (<template>/importNode is your friend if you have a lot of repetitive structure for instance).

That said, this is all fairly academic for most non-benchmark usage. Both approaches are unlikely to have a significant performance impact in real world apps.