Using Tyxml with React is straightforward and makes your pages reactive almost for free.

If your page contains :
p [ text (string_of int i) ]
you juste replace this by
p [ R.text (React.S.map string_of int i) ]

and it is automatically updated when the value of i changes ...

And with Eliom you can even created these reactive pages from server side ...

Vincent


Le ven. 2 déc. 2016 à 14:42, Alain Frisch <alain.frisch@lexifi.com> a écrit :
Hi Vincent,

First, let me insist that I have zero experience with functional
reactive interface, Tyxml or React.  So I'm not in a very good position
to comment on them!

My *intuition* is that the tradeoff would be a bit similar to the one
with Jane Street's Incremental.  Both FRP and SAC require to introduce
extra concepts (signals, events, variables, observers; specific maps and
binds) which add some weight compared to a simple one-directional "view"
mapping from state to vdom.  What you gain with those approaches is a
more fine-grained notion of update, which can be necessary in some cases.

Interestingly, Elm moved away from FRP :
http://elm-lang.org/blog/farewell-to-frp .  This is not just a shift of
terminology, and it corresponds to the removal of the "Address" argument
on the view function in favor of a parametrized vdom type:


https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#no-more-signaladdress

(In a sense, the "Address" argument is rather similar to the "inject"
function which we discussed with Yaron.)


About Tyxml itself: I think that it addresses a rather different set of
issues (ensuring that the DOM is "statically correct" w.r.t. definition
of HTML5/SVG).  We haven't identified those issues as being relevant for
us, i.e. we have never hit a bug related to breaking such validity
constraints, and the lack of static typing does not seem to make
refactoring UI code more difficult or fragile; so it's not clear to us
that adding more static typing here would help.  If we tried to combine
it with our vdom approach, it would probably add some noise, since the
vdom type would receive extra type parameters, which would be visible in
the interface of all components exposing "view" functions.


Alain


On 02/12/2016 13:51, Vincent Balat wrote:
> Hi Alain,
>
> How would you compare the virtual DOM with a functional reactive
> interface, as you can do with Tyxml and React?
>
> -- Vincent
>
> Le mer. 30 nov. 2016 à 17:53, Alain Frisch <alain.frisch@lexifi.com
> <mailto:alain.frisch@lexifi.com>> a écrit :
>
>     Dear all,
>
>     You might be interested in the ocaml-vdom project which has been used by
>     LexiFi for some time and open-sourced recently.  It contains two
>     components which we use to create our browser-side UIs with js_of_ocaml
>     and which might be useful to the community:
>
>         - Bindings to the DOM and other browser APIs, implemented with
>     gen_js_api.  (Partial bindings, expanded on demand.)
>
>         - An implementation of a "virtual DOM" and the "Elm architecture",
>     i.e. a programming model where the UI is specified by a state type, a
>     view function (producing a functional version of the DOM), and an update
>     function that modifies the state based on messages (generated by UI
>     events or external interactions).
>
>
>     Project page:
>
>           https://github.com/LexiFi/ocaml-vdom
>
>
>     -- Alain
>