This is what i wrote in this Reddit thread.
That problem disappears when there is a way to write directly the HTML-DOM in a composable way, using a monoid or a monad. Then, to rewrite any branch, just go to the element and update it also in a composable way. That is what I want to detail below:
Basically, both virtual-dom and react use intermediary lineal images of the dom just to be able to do this:
div [atribute "width" 100] $ ("hello") <> div [attribute "height" 200] "whathever"
But Haskell has a lot more tricks. It is possible to compose functions as monoids. these functions may be builders of DOM elements. these builder functions create dom elements, attributes etc using DOM primitives inside.
That is what ahem.... what my perch library does.
It updates directly the HTML-DOM in a composable way as if they were blaze-html elements IN the browser:
div $ do
div ! atr "width" "100" $ "hello"div ! atr "height" 200 $ "whathever"
and so on.
divhere is a builder function. it can be composed this way, monadically or with a monoid syntax. Both are equivalent, like in the case of the blaze-html library. but while blaze-html concatenate strings, perch concatenate builder functions that create trees. In the above example, in creates a div node with two more divs inside.
Do you want to update an element? modify it directly. Since it does not update an intermediary description, there is no need to detect differences in the intermediate description to avoid to render again the whole description. It simply does it in the DOM.
forElems ".classtochange" $ this ! width "300" ! atr "class" "changed"
The above expression is similar to a jquery modification. it is applied for all the elements that match.
in lineal descriptions like the ones of virtual-dom or react each element is not directly addressable. To address the elements is as expensive as to sequentially rewrite the description with a new one. The need to detect differences is then a consequence of a lineal description. And the lineal description a consequence of the need of composability.
Usage in Reactive Frameworks
I have to say that the virtual-DOM-React approach is ideal for functional reactive frameworks like Elm and others, since them manage the page as a whole. Every signal may change the whole page. I´m not an expert and my knowledge of this is far from accurate, but it seems to me that there are no event scopes, since the events feed a single entry point that re-render the whole page, as far as I know. Or alternatively they modify placeholders in a static template. Without React , Elm and all the functional reactive frameworks were limited to the second option. With it, they can perform more dynamic DOM effects. without React, it was hard to create a responsive TODO application in a functional reactive framework.
Monadic functional reactive may be more promising, since the events can be catched and managed locally (and the DOM updates are local too) they don't affect the whole computation and the re-rendering of the entire page. As the paper is the Google search says: "In other (non monadic) FRP approaches, either the entire FRP expression is re-evaluated on each external stimulus, or impure techniques are used to prevent redundant re-computations". That is the problem that Monadic Reactive solves.
I don´t know how to to slip here hplayground which is a monadic functional reactive framework for Browser applications. For this framework, Perch is perfect. But also is fine as such, with event handlers managed by perch itself.