> 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.