To me both are utter gibberish nonsense. Why? Because of the LIES that make people choose to use them in the first place.

1) Changes to the live DOM are not rendered until scripting is released, as such "batching' changes, doing them in a document fragment, or using the "virtual DOM" makes no difference in speed and only WASTES memory and processing time.

2) Changes to the live DOM are not rendered until scripting is released, as such "batching' changes, doing them in a document fragment, or using the "virtual DOM" makes no difference in speed and only WASTES memory and processing time.

Now I realize this is in fact only one thing, but it's such a colossal sticking point I felt it warranted being said twice.

I guess maybe if you're doing "promises for nothng" on stuff that's not even event driven, in the hot and trendy new form of spaghetti code MAYBE it might serve a purpose for batching changes... but really that's the only time batching or doing it off the live DOM serves any purpose... events.

... and if you don't want your changes taking place until the event finishes, don't make your flipping changes until the event's handler callback runs. Not flipping rocket science.

This Virtual/incremental DOM nonsense is extra code, extra memory, extra processing time, for NOTHING of value. Waste of effort, waste of time, and all predicated on the BALD FACED LIE that directly manipulating the DOM is "bad".

But what can one expect from trash like React or Angular where to update one lousy TD, they refresh the entire TBODY content. /FAIL/ hard.