Can't it batch layout calculations like is typically done in a retained scene graph? You don't do the layout calculations on each change as they occur!
Is it an artifact of the DOM API? In WPF, they have to maintain two sizes because of this: a set size (if specified) and a layout computed size that is filled when layout computations are done in batch. This adds some complexity (e.g. ActualWidth is not always equal of width, and so on), but the perf is pretty good.
> Dirty checking is slower than observables because you must poll the data at a regular interval and check all of the values in the data structure recursively.
You don't have to poll your dirty bits! When you dirty something, you put it into a dirty list/set. You only re-render if your dirty list/set is not empty, clean deeper elements before shallow elements, and its quite optimal.
> A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene.
Totally: they are basically turning a retained model into a not-so-slow immediate model, which is a nice programming abstraction, but it is not a performance win over an efficient retained model.
> DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM.
So layout calculations in normal DOM aren't incremental, but are made incremental in virtual DOM? Assuming this isn't related to batching, it sounds like the concrete DOM is just a bad implementation? Or does the virtual DOM avoid doing layout calculations at all and somehow magically fixes the layout when things change?
Is it an artifact of the DOM API? In WPF, they have to maintain two sizes because of this: a set size (if specified) and a layout computed size that is filled when layout computations are done in batch. This adds some complexity (e.g. ActualWidth is not always equal of width, and so on), but the perf is pretty good.