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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id D3A2080092 for ; Fri, 2 Dec 2016 23:31:24 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout1.mail.janestreet.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.78 as permitted sender) identity=mailfrom; client-ip=38.105.200.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AKwe+cR1bGdOREMtOsmDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seMSLvad9pjvdHbS+e9qxAeQG96KsLQY16L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXbQhEnjWwbLxvJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYO/1jcKPAZtMaXXROUdpNVyJPBYO8?= =?us-ascii?q?apEAD+sHPe1Fq4XwqF8DoR64CAKxBu3g1yVIi2f00q000+ovHwLI0hE+Ed0Sv3?= =?us-ascii?q?rZt8n1NL4IXOyp0KXE0TfOYvVL0jn98ojIdRUhrOmOUr1qa8rRzk8vHB7CgFWR?= =?us-ascii?q?r4zlJDCV1+QQuGWc7+tgUOOvi2g8qwFyojmi3cUshZPPho0L0VDE6T95z5grKt?= =?us-ascii?q?2kUkJ0fdmkEJ5JuiycKoB4TMQiQ2RytyY7zL0LoZ+7fC4QyJQm3RHTcfKHc5KQ?= =?us-ascii?q?7hLsVeaRPTd4hG9+d76lmxmy9k2gxvX8V8au0FZKqS1FnsPQuXAK0hzf8taISv?= =?us-ascii?q?94/ku43TaAzQbT6u5eLUAzj6rbJJgsyaMzmJoLqUnOECz7lF/rgKOKdkgo4Pak?= =?us-ascii?q?5/j7brn8pJKRNJd4hh/iPqkqgMCyAuQ1PhIQU2SG++mwzqDv8En7TbhMk/Y4iL?= =?us-ascii?q?PWsIrAKsQevqO5AxFa0oIk6xunCjen39MYnWQbLF5YYh6HipLmO1DKIPziD/ew?= =?us-ascii?q?mVKsnylwx/DaJL3uHIvCLmTZnLj9erZ97lZQyAs1zd9B+5JZEr8MLfHpVkPsqN?= =?us-ascii?q?DVDgU1PxKoz+r7Etlw1IATVXqKAqCDMaPStVGI5vgoI+mJfIIUuDP9K/kj5/71?= =?us-ascii?q?jn84mUQQfauz0psRdn+4BehmI1+HbnXyntcNC3sFvg07TODykl2NTSZTZ2quX6?= =?us-ascii?q?I7/jw0FJipDYLHRoy0hLyB3Ty7HoFNa2BdClGMFG/oeJ+eV/cNbiKSOM5hnSYe?= =?us-ascii?q?WbivUY9ynS2p4Sb+wrthZsTO+zYTtdq33dx85uuVmwsz7jd0J8CQw2CDTid/mW?= =?us-ascii?q?ZeFBEs26UqkEVnzVHL9Kl+mP9JXYhC4vJPSQQrHZzVyeFhF8r/Vx6HddCMHgX1?= =?us-ascii?q?Cu66CC08G4pii+QFZFxwTpD/1x0=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDI9EFYfU7IaSZcGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgw0BAQEBAXmBBgekSoI3kkWCBiuFdwKCFgd?= =?us-ascii?q?BEgEBAQEBAQEBAQEBEgEBCRYJTYIzGoIbAQEBAwEjBBkBASoCCAMBBAsLCwcGA?= =?us-ascii?q?gIJGgMCAiISAQUBCgEDDgYTCAoCB4g6Aw8IAwugBD+LFWiBbD2DDAEBBYQuA4Q?= =?us-ascii?q?AAQEBAQEBAQEBAQEBAQEBAQEBAQEVCBJ5hTOEW4RJgwSCXYcSDIhhimmGS4pJg?= =?us-ascii?q?XJQjXeHX4YhgkgUHoETJQGBKBMOIxECgxeCJlQBiH0BAQE?= X-IPAS-Result: =?us-ascii?q?A0AVAQDI9EFYfU7IaSZcGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgw0BAQEBAXmBBgekSoI3kkWCBiuFdwKCFgdBEgEBAQEBAQEBA?= =?us-ascii?q?QEBEgEBCRYJTYIzGoIbAQEBAwEjBBkBASoCCAMBBAsLCwcGAgIJGgMCAiISAQU?= =?us-ascii?q?BCgEDDgYTCAoCB4g6Aw8IAwugBD+LFWiBbD2DDAEBBYQuA4QAAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEVCBJ5hTOEW4RJgwSCXYcSDIhhimmGS4pJgXJQjXeHX4Yhgkg?= =?us-ascii?q?UHoETJQGBKBMOIxECgxeCJlQBiH0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,288,1477954800"; d="scan'208";a="202664422" Received: from mxout1.mail.janestreet.com ([38.105.200.78]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 23:31:23 +0100 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout1.mail.janestreet.com with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cCwMU-0007mv-B0 for caml-list@inria.fr; Fri, 02 Dec 2016 17:31:22 -0500 X-JS-Flow: external X-JS-Scanner-attachment: (ok) No attachments Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BYQfY6-AAABTH-Iy; 2016-12-02 17:31:22.282680-05:00 Received: from mail-ua0-f197.google.com ([209.85.217.197]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1cCwMU-00061C-6s for caml-list@inria.fr; Fri, 02 Dec 2016 17:31:22 -0500 Received: by mail-ua0-f197.google.com with SMTP id b35so278754020uaa.1 for ; Fri, 02 Dec 2016 14:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zGBtnHfMRw/9D/s1FAK/N0fw31nPzyuu9ieYmniXoOI=; b=szR+fE9ko9CsN32dI3QkrjlF7P7mUOZPZNSHptMEGfLHQptb81p4t5NDGkjjLND1Ng AjQpC/hQoYuSeTuKC/lLZhGt/6P/wL7ZKgFham6wBnJLXCEpRY8WChM9rBM/nVxpZlE5 wyLzAT/ycD2hUnnjFKY2nqiF39F23BUF/5qFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zGBtnHfMRw/9D/s1FAK/N0fw31nPzyuu9ieYmniXoOI=; b=fLX/Vr0qwshyuV9Qn7r/b2jUdmKBszJfz4UXsXaYc1sQ45qt2zAbFkS6TkID86RBbd evGjyIQZx0KNV9UOD4hPIJ0qYDu2uB2b5U+iCvRWgBujq+5NvZZfWa3QtZqmCzpUx+RG iPrA3Qm0BsVV5bAbboFk1KnsPN/bqLs/2z24KNIS+uACd1uw+qlHuBJOvTLl53sqdAfx YlREk7YrECmDJMaEC6cN9maNFNLcm1xc84NZxi9uwcN59Y2928D2dLOpp2QhYR4ubkB7 gckQYdGcGY7IlWOox7Jpw4F1LUv6p3a4XvtFmPRxn+UfpS4cpAqoHTL0rNU+BvwfD7c6 aQ1g== X-Gm-Message-State: AKaTC03rOQY5brCCJ1CAVZgbmguWPywiUfUa1KNPmxhcprUMCKtR4TNi25vyVHgichpK713UIi07t0LTK/DNWIY/Ej9m6MpXduhJu0XGILLwX2TPSxaoFyBV4oqVS4nlrlDEcIUroWHwZa1V+Xvk X-Received: by 10.159.48.91 with SMTP id i27mr35407329uab.13.1480717881720; Fri, 02 Dec 2016 14:31:21 -0800 (PST) X-Received: by 10.159.48.91 with SMTP id i27mr35407315uab.13.1480717881440; Fri, 02 Dec 2016 14:31:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.229.193 with HTTP; Fri, 2 Dec 2016 14:31:00 -0800 (PST) In-Reply-To: <4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com> References: <96757896-e79c-f940-fc3a-090fc1419df2@lexifi.com> <4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com> From:Yaron Minsky Date: Fri, 2 Dec 2016 17:31:00 -0500 Message-ID: To:Alain Frisch Cc:Vincent Balat , ocsigen@inria.fr, OCaml Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Announce: ocaml-vdom (pre-release) On Fri, Dec 2, 2016 at 8:41 AM, Alain Frisch wrot= e: > 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 constraint= s, > and the lack of static typing does not seem to make refactoring UI code m= ore > difficult or fragile; so it's not clear to us that adding more static typ= ing > here would help. If we tried to combine it with our vdom approach, it wo= uld > 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 =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 >> > > -- > 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