Re: [Caml-list] Announce: ocaml-vdom (pre-release)

[Yaron Minsky <yminsky@janestreet.com>]

On Fri, Dec 2, 2016 at 8:41 AM, Alain Frisch <alain.frisch@lexifi.com> wrote:
> 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.

I think FRP and SAC are pretty different in their roles here. Really,
SAC is just a system for optimizing a unidirectional computation ---
in the end, your view is pretty close to a function of this signature:

val view : Model.t Incr.t -> Vdom.t Incr.t

which is really just an incremental version of an ordinary function.
You don't have to think about anything signal-like when you consider
the semantics of your function: the semantics are exaclty what you get
if you replaced every monadic bind with an ordinary let-binding.

My somewhat biased view is that SAC addresses performance, which is an
issue of fundamental importance for UIs, whereas FRP doesn't address a
problem which is similarly central.  And the ability to express
time-dependent computations (which FRP provides) adds lots of other
problems (in particular, monadic FRP is plagued by space leaks.)

> 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.)

Having talked to Evan a decent amount about this, my takeaway is that
FRP in Elm wasn't really used to improve performance, and without
that, it wasn't worth the conceptual weight.

Incremental adds some conceptual weight (less, I claim, than
traditional FRP libraries), but it also solves a real problem.

React and Elm style solutions are simply not capable of implementing
highly efficient views of fast changing data; indeed, they typically
use special-purpose imperative libraries for implementing applications
that require it.  Incremental lets you do this kind of optimization in
one smooth, functional framework.

The cost, obviously, is you need to be comfortable living in a monad.
For our developers, this doesn't count as that much of a cost these
days, given the proliferation of other monadic abstractions in our
code. But it's not trivial.

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

We support both TyXML and a simpler, untyped vdom API. My personal
view pretty much matches yours, but other users (Hugo Heuzard in
particular) prefers it pretty strongly.

The lack of an extra type parameter in our approach makes the
integration with TyXML easier, I suppose.

y

> 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
>>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs