To use incremental Dom with blaze we have to throw out quite a bit. Blaze is very low level - it implements its own incremental Dom. Switching to Google’s idom implementation is essentially removing meteor’s own ‘idom’ in favor of someone else’s.
Why would we do that? It’s working now. We barely have enough community resources, why waste them. Not to mention that we have to convince people that there is value in doing that so they dedicate their time to it.
Oh, I use “incremental DOM” and “virtual DOM” as a similar thing. It is the question of optimizing the materializer layer. And we should probably investigate which one is more suitable for Blaze. Incremental DOM seemed more suitable because it looked like it would be easier to adapt, but @ramez is reporting that this is not so. So, we can try then virtual DOM, which already has some precedent with Blaze.
Again, I am not saying that we should not be optimizing the reactivity, but that we should also investigate improvements to DOM layer rendering.
And for reactivity, it would be great to join the discussion there, because that was discussed already before and I think there even better solutions were suggested than this patch which changes defaults. So, if people want to join the discussion about reactivity, they should read this and this first
I looked at the repo you linked to. Doesn’t seem to be a proper / complete implementation. The whole of Blaze is still there. What I think the developer did was render from Blaze to vDOM then vDOM to actual DOM. So he didn’t solve the same issue I faced, is that the Blaze implementation is already low-level.
Incremental DOM was meant for (originally) non-reactive templating engines (like Mustache and Handlebars). So it’s easy to patch them up; instead of making direct DOM calls (document.createElement) they use the Incremental DOM API (elementOpen and elementClose). The change to the code base is minimal for such templates. But for us, it’s big. You have to flush out so much to get back the same functionality you had before 
with someone else’s library …
[Edit: Removed my non-funny comment at end]
@sashko, after reading this thread, what’s your opinion (or will you pull someone in that can provide new insights)?
I think people who use Blaze daily in their production apps are the best equipped to have opinions on this! I don’t.
Personally I never had performance issues in Blaze rendering - they were all related to Tracker stuff rerunning too often, or unexpectedly.
Can anyone comment on the state of incremental DOM? Is it “complete” and is Google committed to maintaining it?
I think implementing it would give credibility to Blaze, as it has a fancy-DOM utility underneath and one that is Google-backed.
Another, less attractive path, is to re-brand Blaze’s rendering engine. Maybe “Incremental DOM” would apply, or “Reactive DOM”, or something
Will you please pull someone in at MDG that has more of an opinion if you can?
I posted it on our internal Slack channel, so people can join in if they are interested.
Agreed! This is what we saw too.
We can confirm this. Making sure you don’t update too much data, don’t rerun trackers etc. is the most important part. That being said I cannot compare it without seeing a Virtual DOM implementation, maybe that is actually a strong improvement on performance and user experience.
We even build custom counters in our apps to check the behavior and we check the end-result of those counters in our end-to-end tests. That way we detect sudden changes in rising amounts of rendering / updates / etc. so we can take a decision on them.
Maybe that’s something for @msavin to add to Toys (if it’s not already in there).