Browser programming: React.js as a solution for a problem that Haskell can solve in better ways

This is what i wrote in this Reddit thread.

IMHO virtual-dom as well as React tries to solve a problem specific of javascript: the lack of a intuitive, composable way to update the HTML-DOM tree. So it creates a composable intermediary, a lineal virtual-dom. Basically, it is string concatenation. When changed, the intermediary lineal description is rendered. But the rewrites and re-rendering are expensive, so they need to update only what is changed.

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"

Since strings are composable in javascript as well as in any language. But trees are not.

That composable syntax is impossible in javascript with the HTML DOM directly.

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.

https://github.com/agocorona/haste-perch

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. div here 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.

But a set of monoidal combinators of functions that update the DOM are composable . And it is pure Haskell, no need to use Javascript libraries.

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.