Create a separate initial rendering pass about incremental-dom HOT 3 CLOSED

Would it be possible to combine this with #50? I know from the examples provided that patching a DOM tree that does not have __incrementalDOMData is possible. My idea is to inject the HTML generated by such interface via innerHTML. The benefits I see are:

• Faster DOM node creation for an initial pass.
• Would mitigate problems with <input> and type definition for IE8 (most of the times, type is kept constant, so just initializing it correctly the first time would solve the issue, see #60).
• As stated in #50, this would also let you render in the server.

In any case, if this is the used approach, I think I would let this outside the standard incremental DOM implementation, so the library keeps its small size.

from incremental-dom.

Lots of good points. I had experimented with generating innerHTML'd strings a while ago. Some things to consider:

• If you are attaching things that are properties (e.g. extra objects you want to store), you may want to do a normal diff pass shortly after the initial render
• innerHTML is faster, but not hugely faster than pure createElement and setAttribute (something like 25% if I recall correctly)
• Need to have logic to escape attribute values and text nodes, in the worst case (lots of text data), this can be a significant amount of time and may cause pure createElement to be faster (a bit fuzzy on this one but I think that is what I saw)

As you said, it should probably be outside the core library. I'm not sure if this repo would be a good place (considering #141) or if perhaps it should be another project entirely.

from incremental-dom.

After looking at the high mutation case, it seems like solving that problem also helps solving the initial creation case (since that is really just a diff with everything as a mutation). It doesn't seem like having this in the core library is really desirable.

from incremental-dom.