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 320677EE9C; Thu, 1 Dec 2016 10:32:17 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=alain.frisch@lexifi.com; spf=None smtp.mailfrom=alain.frisch@lexifi.com; spf=None smtp.helo=postmaster@vrout10.yaziba.net Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=185.56.204.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=185.56.204.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@vrout10.yaziba.net) identity=helo; client-ip=185.56.204.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="postmaster@vrout10.yaziba.net"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AViOCNBJYEhzSWuVuBNmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgfL/nxwZ3uMQTl6Ol3ixeRBMOAuqkC17Kd6vqwEUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6zbL9oIxi6sQrdutQIjYZhN6081gbHrnxUdu?= =?us-ascii?q?pM2GhmP0iTnxHy5sex+J5s7SFdsO8/+sBDTKv3Yb02QaRXAzo6PW814tbrtQTY?= =?us-ascii?q?QguU+nQcSGQWnQFWDAXD8Rr3Q43+sir+tup6xSmaIcj7Rq06VDi+86tmTgLjhT?= =?us-ascii?q?wZPDAl7m7Yls1wjLpaoB2/oRx/35XUa5yROPZnY6/RYc8WSW9HU81MVSJOH5m8?= =?us-ascii?q?YpMSAeQfM+ZWr4rzqVUAohSxBwajGOzhxyRUhnL0x6A2z/gtHA/E0QEmAtkAsG?= =?us-ascii?q?7UrNLwNKoKTe21yLPHzTTFb/hL2Tn98onIcgs9rvGMQLl9dtDeyU01GAPEiFWc?= =?us-ascii?q?s4LlPymU1uQWr2eb7/FtVeaxhG8oqgFxrDmvyt0whYnOg4IY01bJ/jh3zoYyIN?= =?us-ascii?q?23Uk97Ydi8HZtftiGaK4t2Qt45TG1ypCk6zbgGtYalcygOzZQr3hrfZOaBc4iH?= =?us-ascii?q?+B7jU/yRITh+iXl4e7y/nw6//VWjx+D8TMW50FdHojBbntXQuX0BzRLe58efRv?= =?us-ascii?q?dg/Uqs2SyD2x7d5+1eJU04i7DXJ4Muz7M/kJcYrF7NETXsmErsia+bbkUk9fas?= =?us-ascii?q?6+TgerjmuIWcN4hpigHiL6gihtazAOQiPQkPXmiU4v6z2Kfl/ULnXLVGlvw2kq?= =?us-ascii?q?/Hv5DGPckXu620Dg9P3osj6huzFSmq3MgXkHUdIl9IdwqLj43zNFHPJPD4A+2/?= =?us-ascii?q?g1OpkDpz3f/GOqfuApTLLnTZnrfhZ7d961VAxwoz1t1f44xbC74AIPL9W0/9rs?= =?us-ascii?q?DXDhg8MwCs2eboFM191p8CWWKIGqKWLLndsVqM5u42J+mMZZQVuCrmJvg+5//u?= =?us-ascii?q?iGc5lkUHcamo25sXcnG4Ee58L0WXe3rmms0BHnsSvgoiUOzqj0WPUTlPaHapXq?= =?us-ascii?q?I86S80CIS9AIfYRoGthaSB0z2hEp1XYGBGEFGMHm3ye4WKQfcAcCeSIsh8nTMa?= =?us-ascii?q?TbWhUIoh1Q22tA/91rpnMrmcxipNhJv50949wuzVjhIjvWhlCsWbyGKcZ2N9mG?= =?us-ascii?q?4TWyU70bw5qkt4nASty6991tVcHN1Vr91TUxwxNdaIxuhzCta0VBjAZdyJYFKr?= =?us-ascii?q?UtSoAHc6SddnkIxGWFp0B9j31kOL5CGtGbJA0uXTXJE=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAAD77D9YhyLMOLlUCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBARUBAQEBAgEBAQEIAQEBAYMNAQEBAQF3gQMBpE8Olm8phXkCgjsQAQE?= =?us-ascii?q?BAQEBAQEBAQESAQEBCgsJCR0wgjMaAYIaAQEBAwEjBBFBBQsLDgoCAhEVAgJXB?= =?us-ascii?q?g0IAQGIYQwBCatzgWw9i08BAQEBAQUBAQEBAQEhgQuFM4F9CIJWhCIRVYJFgl0?= =?us-ascii?q?FlHOFaYF4hFODEIc1gkKHSIYriheDYYQKAjWBGESDORELgV5xAQGJQAEBAQ?= X-IPAS-Result: =?us-ascii?q?A0CpAAD77D9YhyLMOLlUCRoBAQEBAgEBAQEIAQEBARUBAQE?= =?us-ascii?q?BAgEBAQEIAQEBAYMNAQEBAQF3gQMBpE8Olm8phXkCgjsQAQEBAQEBAQEBAQESA?= =?us-ascii?q?QEBCgsJCR0wgjMaAYIaAQEBAwEjBBFBBQsLDgoCAhEVAgJXBg0IAQGIYQwBCat?= =?us-ascii?q?zgWw9i08BAQEBAQUBAQEBAQEhgQuFM4F9CIJWhCIRVYJFgl0FlHOFaYF4hFODE?= =?us-ascii?q?Ic1gkKHSIYriheDYYQKAjWBGESDORELgV5xAQGJQAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,724,1477954800"; d="scan'208";a="202433330" Received: from vrout10-bl.yaziba.net (HELO vrout10.yaziba.net) ([185.56.204.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2016 10:32:16 +0100 Received: from mtaout10.int.yaziba.net (mtaout10.int.yaziba.net [10.4.20.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vrout10.yaziba.net (mx10.yaziba.net) with ESMTPS id 1762A51F1B; Thu, 1 Dec 2016 10:32:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mtaout10.int.yaziba.net (Postfix) with ESMTP id 229BC16016C; Thu, 1 Dec 2016 10:32:15 +0100 (CET) X-Virus-Scanned: amavisd-new at Received: from mtaout10.int.yaziba.net ([127.0.0.1]) by localhost (mtaout10.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DtKxJsKcSmgc; Thu, 1 Dec 2016 10:32:15 +0100 (CET) Received: from [10.0.210.40] (unknown [185.23.92.144]) by mtaout10.int.yaziba.net (Postfix) with ESMTPSA id DCAB916014F; Thu, 1 Dec 2016 10:32:14 +0100 (CET) To: Yaron Minsky References: <96757896-e79c-f940-fc3a-090fc1419df2@lexifi.com> Cc: ocsigen@inria.fr, OCaml Mailing List From: Alain Frisch Message-ID: <0f6d69bb-a458-5876-3c60-a29befab02d1@lexifi.com> Date: Thu, 1 Dec 2016 10:32:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeelfedrgedugddtiecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheptehlrghinhcuhfhrihhstghhuceorghlrghinhdrfhhrihhstghhsehlvgigihhfihdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpvghlmhdqlhgrnhhgrdhorhhgnecukfhppedukeehrddvfedrledvrddugeegnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] Announce: ocaml-vdom (pre-release) Hi Yaron, On 30/11/2016 20:22, Yaron Minsky wrote: > I'm curious if you have any story for making the recomputation of the > virtual-dom itself more efficient. > ... > That said, for small UIs, this kind of incrementality is less > important, so whether this is worth doing may depend on your > applications. Our story w.r.t. updating the vdom itself is the same as Elm, I believe: 1. In the vast majority of cases, the mapping from the "state" to the vdom is very quick and it is ok to recompute the full vdom on every state change. An argument often made in the vdom space is that a UI usable by human-beings cannot possibly have a very big DOM (moreover, even recent browsers such as the latest Edge or Firefox struggle with tables starting at a few thousands rows), and that computing the full vdom "cannot be that costly". I don't want to enter such discussion here, but in our own use cases, we indeed try to avoid "overly big UIs" and we don't have strong performance requirements such as continuous streams of updates pushed by the server; if it takes 10ms to react on a user UI event, it is perfectly fine for our case. My intuition is that most applications would be a similar situation, but I appreciate that you have very different kinds of UIs and performance constraints that require a more incremental approach. 2. The library provides: val memo: ?key:string -> ('a -> 'msg vdom) -> 'a -> 'msg vdom (** Apply the function to generate a VDOM tree only if the function or its argument have changed (physically) from the previous synchronization. *) (similar to Elm's Lazy: http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy ) This is typically used when embedding the view of a "sub-component" derived from only part of the our current state. If we can ensure this sub-part remains the same, the previous vdom (at the same "site") is reused, which skips both the vdom generation and the vdom diffing. Typically, the generation function would be a toplevel declaration (so it will always be the same, physically) and we arrange to avoid touching the part of the global state on which it depends. Of course, it is also possible to use any other mechanism (such a memoization table) to reuse previously computed vdoms. > Another thought: you might want to consider the design we used for our > wrapper on Matt Esch's virtual-dom library. In particular, in our > design we don't need a type-parameter for vdom nodes determining the > type of a message, and we don't need the corresponding map > functions. Instead, we use open types and a registration and dispatch > mechanism for values thus injected. Thanks for the hint. Do you have pointers to code examples using the "inject" function? It seems to me that you will need to apply to it produce any "message" in the view function. In our library, you can write directly: input "+" ~a:[value "+"; type_button; onclick `Plus] With the "inject" approach, do you need to write it like: input "+" ~a:[value "+"; type_button; onclick (inject `Plus)] ? If so, this does not seem strictly lighter than using the "map" function occasionally. Moreover this seems to open the door to possible problems if a vdom fragment producing some kinds of messages is injected in a "host application" that cannot process these messages. It also means that one needs to take the identity of the "inject" function itself into account in order to memoize vdom-generation functions. Basically, we need "map" on "component boundaries", and even not always, since components can take ad hoc injection functions to wrap their messages into their "host" own message type (as the SelectionList example in https://github.com/LexiFi/ocaml-vdom/blob/master/examples/vdom_ui.mli ). The library does use extensible types (with a registration/dispatch mechanism) in two other places, though: - "Commands" (encapsulation of side-effectul operations). The set of "command constructors" is small and has a global nature (e.g. "AJAX query", "timer", etc), while the type of "messages" is specific to each application and component. - "Custom nodes" in the VDOM which allow plugging "native" components (again, the set of such possible components is more "fixed" than messages). Alain