From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 08B4180091; Fri, 2 Dec 2016 17:59:38 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=vincent.balat@vblt.org; spf=None smtp.mailfrom=vincent.balat@vblt.org; spf=None smtp.helo=postmaster@relay3-d.mail.gandi.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of vincent.balat@vblt.org) identity=pra; client-ip=217.70.183.195; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="vincent.balat@vblt.org"; x-sender="vincent.balat@vblt.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of vincent.balat@vblt.org) identity=mailfrom; client-ip=217.70.183.195; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="vincent.balat@vblt.org"; x-sender="vincent.balat@vblt.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@relay3-d.mail.gandi.net) identity=helo; client-ip=217.70.183.195; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="vincent.balat@vblt.org"; x-sender="postmaster@relay3-d.mail.gandi.net"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AIOvhxxHr4EY7zVr/WPtbIZ1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ74psWwAkXT6L1XgUPTWs2DsrQf2rGQ7/urBTFIoc7Y9itdINoUD15NoP?= =?us-ascii?q?5VtjJjKfbNMVf8Iv/uYn5yN+V5f3ghwUuGN1NIEt31fVzYry76xzcTHhLiKVg9?= =?us-ascii?q?fbytScb6xv663OGq+pDVfx4AxH/kOeszf12KqlD4ssAXh8NMMKcqwRuB9nJMcu?= =?us-ascii?q?VQg21yJEmYnz7469ex8p8l+CNV7bZpyc9GWqj8Y+wSRLhREHxyLWEz78DtqV/J?= =?us-ascii?q?RA+G+lMbWX4XnRdORQ/f40e+FpD6qSr1u+xV2S+APMSwQ6pwEROJ5qJvADrhiS?= =?us-ascii?q?MGMTFx1GDMloQkh6tepFelpgdj64/SeoCccvRkKPDzZ9QfEFRAWM1cUTAJKIq4?= =?us-ascii?q?ZpdHW/QAO+1VqZW7rVIKpAeWGwOoGKXo0DAe1Sy+5rEzz+l0SVKO5wcnBd9b9S?= =?us-ascii?q?2M9Ng=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAADup0FYh8O3RtlcHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgw0BAQEBAXmBBgcBpEiPWocoK4V3AoIaQhEBAQEBAQEBAQEBARI?= =?us-ascii?q?BAQEIDQkJHTCCMwQBFQEEghYBAQEDASNJCggLCQILBwYnAwICIhIBBQELAw4GA?= =?us-ascii?q?RIUiFMIBAqOfZELP4t9gimLMQEBAQEGAQEBAQEBASCFRXmEW4QzgxqCXQWaY4F?= =?us-ascii?q?4hFOKSYFyjkeHX4YhgkgygRECNYEZVQKDN4FocgGHLkIBgQwBAQE?= X-IPAS-Result: =?us-ascii?q?A0BSAADup0FYh8O3RtlcHAEBBAEBCgEBFwEBBAEBCgEBgw0?= =?us-ascii?q?BAQEBAXmBBgcBpEiPWocoK4V3AoIaQhEBAQEBAQEBAQEBARIBAQEIDQkJHTCCM?= =?us-ascii?q?wQBFQEEghYBAQEDASNJCggLCQILBwYnAwICIhIBBQELAw4GARIUiFMIBAqOfZE?= =?us-ascii?q?LP4t9gimLMQEBAQEGAQEBAQEBASCFRXmEW4QzgxqCXQWaY4F4hFOKSYFyjkeHX?= =?us-ascii?q?4YhgkgygRECNYEZVQKDN4FocgGHLkIBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,287,1477954800"; d="scan'208,217";a="247856498" Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 17:59:37 +0100 Received: from mfilter47-d.gandi.net (mfilter47-d.gandi.net [217.70.178.178]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 11CEFA80E4; Fri, 2 Dec 2016 17:59:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter47-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter47-d.gandi.net (mfilter47-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 1hnlMoog_vm0; Fri, 2 Dec 2016 17:59:34 +0100 (CET) X-Originating-IP: 74.125.82.45 Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (Authenticated sender: v@vblt.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 89E9DA80F9; Fri, 2 Dec 2016 17:59:34 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id f82so21241876wmf.1; Fri, 02 Dec 2016 08:59:34 -0800 (PST) X-Gm-Message-State: AKaTC02/Haj/Mb0qRFLUqd83IKTdEsF9CGKOHy9wIMuc9ZEyV1B3Pijwzt6/CJtWZg8/ARpUnqEXtlxpkCKGmw== X-Received: by 10.28.185.78 with SMTP id j75mr3750850wmf.14.1480697974237; Fri, 02 Dec 2016 08:59:34 -0800 (PST) MIME-Version: 1.0 References: <96757896-e79c-f940-fc3a-090fc1419df2@lexifi.com> <4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com> In-Reply-To: <4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com> From: Vincent Balat Date: Fri, 02 Dec 2016 16:59:23 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Alain Frisch , Vincent Balat , ocsigen@inria.fr, OCaml Mailing List Content-Type: multipart/alternative; boundary=001a1148d640c674600542afdca3 Subject: Re: [Caml-list] Announce: ocaml-vdom (pre-release) --001a1148d640c674600542afdca3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A9c. 2016 =C3=A0 14:42, Alain Frisch a =C3=A9crit : > 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 =C3=A0 17:53, Alain Frisch > > a =C3=A9crit : > > > > 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 > > > --001a1148d640c674600542afdca3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Using Tyxml with React is straightforward and mak= es your pages reactive almost for free.

If your pa= ge contains :
p [ text (string_of int i) ]
you juste re= place this by
p [ R.text (React.S.map string_of int i) ]

and it is automatically updated when the value of i change= s ...

And with Eliom you can even created these re= active pages from server side ...

Vincent


Le= =C2=A0ven. 2 d=C3=A9c. 2016 =C3=A0=C2=A014:42, Alain Frisch <alain.frisch@lexifi.com> a =C3=A9cri= t=C2=A0:
Hi Vincent,

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

My *intuition* is that the tradeoff would be a bit similar to the one
with Jane Street's Incremental.=C2=A0 Both FRP and SAC require to intro= duce
extra concepts (signals, events, variables, observers; specific maps and binds) which add some weight compared to a simple one-directional "vie= w"
mapping from state to vdom.=C2=A0 What you gain with those approaches is a<= br class=3D"gmail_msg"> 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= .=C2=A0 This is not just a shift of
terminology, and it corresponds to the removal of the "Address" a= rgument
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 &quo= t;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. defi= nition
of HTML5/SVG).=C2=A0 We haven't identified those issues as being releva= nt 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<= br class=3D"gmail_msg"> that adding more static typing here would help.=C2=A0 If we tried to combin= e
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 =C3=A0 17:53, Alain Frisch <alain.frisch= @lexifi.com
> <mailto:alain.frisch@lexifi.com>> a =C3=A9crit : >
>=C2=A0 =C2=A0 =C2=A0Dear all,
>
>=C2=A0 =C2=A0 =C2=A0You might be interested in the ocaml-vdom project w= hich has been used by
>=C2=A0 =C2=A0 =C2=A0LexiFi for some time and open-sourced recently.=C2= =A0 It contains two
>=C2=A0 =C2=A0 =C2=A0components which we use to create our browser-side = UIs with js_of_ocaml
>=C2=A0 =C2=A0 =C2=A0and which might be useful to the community:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Bindings to the DOM and other brows= er APIs, implemented with
>=C2=A0 =C2=A0 =C2=A0gen_js_api.=C2=A0 (Partial bindings, expanded on de= mand.)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- An implementation of a "virtua= l DOM" and the "Elm architecture",
>=C2=A0 =C2=A0 =C2=A0i.e. a programming model where the UI is specified = by a state type, a
>=C2=A0 =C2=A0 =C2=A0view function (producing a functional version of th= e DOM), and an update
>=C2=A0 =C2=A0 =C2=A0function that modifies the state based on messages = (generated by UI
>=C2=A0 =C2=A0 =C2=A0events or external interactions).
>
>
>=C2=A0 =C2=A0 =C2=A0Project page:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://github.com/LexiFi/ocaml-vdom
>
>
>=C2=A0 =C2=A0 =C2=A0-- Alain
>
--001a1148d640c674600542afdca3--