[sod]

I always wonder why github doesn't do something like this. Right now they return html via ajax and innerHTML it into the DOM. Given that innerHTML is notoriously slow, returning something like this should be way faster.

Your lib seems to lack svg & @types support though. And I don't know why you have "virtual DOM" in the title, given that it has nothing to do with it :)

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

[klysm]

Just rails things