caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <alain.frisch@lexifi.com>
To: Vincent Balat <vincent.balat@ocsigen.org>,
	ocsigen@inria.fr, OCaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Announce: ocaml-vdom (pre-release)
Date: Fri, 2 Dec 2016 14:41:55 +0100	[thread overview]
Message-ID: <4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com> (raw)
In-Reply-To: <CAG+nEjzO1qFfxHSMqueiKcTJyJYnREmvXhzGR7H+noBmV2oUKw@mail.gmail.com>

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
>

  parent reply	other threads:[~2016-12-02 13:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 16:52 Alain Frisch
2016-11-30 19:22 ` Yaron Minsky
2016-12-01  9:32   ` Alain Frisch
2016-12-01 22:18     ` Yaron Minsky
2016-11-30 22:46 ` Martin DeMello
2016-12-01  9:56   ` Alain Frisch
     [not found] ` <CAG+nEjzO1qFfxHSMqueiKcTJyJYnREmvXhzGR7H+noBmV2oUKw@mail.gmail.com>
2016-12-02 13:41   ` Alain Frisch [this message]
2016-12-02 16:59     ` Vincent Balat
2016-12-02 18:18       ` Alain Frisch
2016-12-02 22:31     ` Yaron Minsky
2016-12-10 13:34       ` SP
     [not found]     ` <5db7c03d-bec8-8285-b458-82e681842dbb@zoho.com>
2016-12-05 15:55       ` Ashish Agarwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com \
    --to=alain.frisch@lexifi.com \
    --cc=caml-list@inria.fr \
    --cc=ocsigen@inria.fr \
    --cc=vincent.balat@ocsigen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).