This is a brain dump.
From Binding.scala github readme: "it is a template that describes the relationship between data source and the DOM. When partial of the data source changed, the Binding.scala framework understands the exact partial DOM corresponding to the partial data. Then, Binding.scala only re-evaluates partial of the @dom method to update the partial DOM."
I dont fully understand Binding.scala but it reminds me of John Degoes's talk on Purescript Halogen, which had a slide something like this:
UI :: State -> HTML
ΔUI :: Δstate -> ΔHTML;
UI = reduce(ΔUI, Δstates)
Essentially, if react lets us define our
UI :: State -> HTML, incremental lets us define ΔUI :: Δstate -> ΔHTML, such that the runtime evaluates the app as a reduce over a stream of state changes. This will give us back our function laws and be fast and work with graph values in state, but the types involved are complex. Incremental also loses the intuitive nature of react though where it feels like we are defining html templates. Thinking in terms of Δhtml templates, i dont even know what that would make the ui code look like, probably something like redux reducers. But it would be correct and optimal performance?
There are performance reasons to prefer incremental rendering. 1) you don't need to hold the entire state in memory, just the delta. 2) you don't need to re-compute the entire dom. React provides render-tree pruning to help this issue, but that is only useful if our state is tree-like, but in apps with graph-like state, tree pruning is a lot less useful. this is why om next has an indexer and reconciler - which leads me to my question, because i think that if we had incremental html updates we don't need indexer/reconciler to work with graph-like state. Also in clojure we code with incremental updates like assoc and update-in all the time. me @ /r/clojure
For more about incremental UIs, read Incremental computation and the web (Jane Street).