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 C7A6580070; Mon, 5 Dec 2016 16:56:19 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=agarwal1975@gmail.com; spf=Pass smtp.mailfrom=agarwal1975@gmail.com; spf=None smtp.helo=postmaster@mail-ua0-f178.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of agarwal1975@gmail.com) identity=pra; client-ip=209.85.217.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of agarwal1975@gmail.com designates 209.85.217.178 as permitted sender) identity=mailfrom; client-ip=209.85.217.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ua0-f178.google.com) identity=helo; client-ip=209.85.217.178; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-ua0-f178.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AHhtSLRPOd1L1m08n48kl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0KPz5rarrMEGX3/hxlliBBdydsKMfzbaG+PqwESxYuNDa7yBEKMQNHzY+yu?= =?us-ascii?q?wo3CUYSPafDkP6KPO4JwcbJ+9lEGFfwnegLEJOE9z/bVCB6le77DoVBwmtfVEt?= =?us-ascii?q?fre9Msfogs+2z+G//YHIK0UN3WLlIOA6EBLjgR/MroFCjZF/Mrc2xTPbpXtPPe?= =?us-ascii?q?9RwDU7C0iUmkPV/cex554r2itZoe0o84YUWKrzZbsxSeUJU2kOPGU85cmtvh7G?= =?us-ascii?q?G1jcrkAAW3kbx0IbSzPO6wv3C9Ko6nP3?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAQA1jUVYhrLZVdFdHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgw0BAQEBAYF/B6RJiGSEFIoNhiICggsHQhEBAQEBAQEBAQEBARI?= =?us-ascii?q?BAQEICwsJHTCCMwQBFQEEghcBBAEjHQEbHQEDDAYFBAc3AgIiAREBBQEcBhOIV?= =?us-ascii?q?AEDAQQKCJ5IP4t9ggQFAR+DDQWDWgoZJw0YPIMiAQEBAQEFAQEBAQEBARgCBhK?= =?us-ascii?q?LB4dMgl0FgSUBAQGOVIpgCAEBgTMJj1uQPY4CgkgUHoETNYEZVSWCdCCCCB40h?= =?us-ascii?q?yqBTwEBAQ?= X-IPAS-Result: =?us-ascii?q?A0AKAQA1jUVYhrLZVdFdHAEBBAEBCgEBFwEBBAEBCgEBgw0?= =?us-ascii?q?BAQEBAYF/B6RJiGSEFIoNhiICggsHQhEBAQEBAQEBAQEBARIBAQEICwsJHTCCM?= =?us-ascii?q?wQBFQEEghcBBAEjHQEbHQEDDAYFBAc3AgIiAREBBQEcBhOIVAEDAQQKCJ5IP4t?= =?us-ascii?q?9ggQFAR+DDQWDWgoZJw0YPIMiAQEBAQEFAQEBAQEBARgCBhKLB4dMgl0FgSUBA?= =?us-ascii?q?QGOVIpgCAEBgTMJj1uQPY4CgkgUHoETNYEZVSWCdCCCCB40hyqBTwEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,305,1477954800"; d="scan'208,217";a="248160934" Received: from mail-ua0-f178.google.com ([209.85.217.178]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 05 Dec 2016 16:56:18 +0100 Received: by mail-ua0-f178.google.com with SMTP id 51so352329506uai.1; Mon, 05 Dec 2016 07:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PeIyLzmP0D/FIK2YSVRaLbYs8Db/m0ocYiuTPneztPo=; b=EWslDUmshskFk24DJ/e8udODWLa2My4iPNe0eoIPOZSOjNzIlGCQmx6Syn+3gHP1w3 yHqwMgn+Of5jBq2ZXymCLLiwMTMceQ70gsdT7HRaUnd/f2E6l40uKv7lt0p9daIkGfMC V+deRE8w+WM4bjbHRYnNRrY9RFPHE9S3etdBsfjaTVFG3HJazItw5uN1mqE+S3MsOGGb vQ7zWcQgktkL6AJLouM47CAHYZjOoar1g5ajAQzYFNN6PJBw/eytujhDZGPyULHLIfGz N0K+UfluDHen77LRRxwgL9MmfHC2uIe4JI8XRay6WzCMrI31gBRF0u4UXxsNSCU47fVo XoCg== 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; bh=PeIyLzmP0D/FIK2YSVRaLbYs8Db/m0ocYiuTPneztPo=; b=VFYG+9Iiyq0MOeqB4LIyHDfYko4jAa9NXhFAsmv9a3lHhmGVGjbGPrCb9xmTIqywoj /oVbS/BYqm21sFDpuAGF8WuOsYr+CBdpZxQWACHmAb7PbFRbXFmWznReGy4hS5xyhE5m Sxg9HugO98o9Q5wzsfCmAbz0rlg56LuUAPhJE+RFbpLAnJd+6IkxnSFQci1b4YKZ6VM+ V+aNu7NhAUgUzXEnUP/9NoONBjczRRrTV0lQflyaIXagcy8FlgpD/HNl0p9YvjRwIIFz /kOfJHPHEJlfIp6cqJc1c8BZfA6zhqwHoXS5Q3Oo4zcxdIx2puX8eC+ZDneUv6DRZGuq 6Cvg== X-Gm-Message-State: AKaTC02EBUKhNx4wkvaW9xnXzm0K2uS8AuVf6BRlsEa0z2QySD0DWdEwPabE7hSm1AvNHijwWHO/AOyC6MP2yg== X-Received: by 10.176.81.82 with SMTP id f18mr44404201uaa.119.1480953377861; Mon, 05 Dec 2016 07:56:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.146.131 with HTTP; Mon, 5 Dec 2016 07:55:57 -0800 (PST) In-Reply-To: <5db7c03d-bec8-8285-b458-82e681842dbb@zoho.com> References: <96757896-e79c-f940-fc3a-090fc1419df2@lexifi.com> <4b5b6340-0cdd-abc1-b6dc-b97e3d6b9cdf@lexifi.com> <5db7c03d-bec8-8285-b458-82e681842dbb@zoho.com> From: Ashish Agarwal Date: Mon, 5 Dec 2016 08:55:57 -0700 Message-ID: To: Drup Cc: Alain Frisch , Vincent Balat , ocsigen , OCaml Mailing List Content-Type: multipart/alternative; boundary=94eb2c1913b60438390542eb54f7 Subject: Re: [Caml-list] Announce: ocaml-vdom (pre-release) --94eb2c1913b60438390542eb54f7 Content-Type: text/plain; charset=UTF-8 I don't have a strong opinion either way, but one point not mentioned about Tyxml is that you get nice auto-completion when combined with merlin. I've been pleased to learn the possible values for some attributes while coding without having to reference any documentation. On Sat, Dec 3, 2016 at 10:27 AM, Drup wrote: > > 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. >> > > Tyxml is not only about type-safety. It's about providing an exhaustive, > consistent and convenient HTML5 API for your users. > > Tyxml also gives you combinators covering the complete HTML5 surface API. > This API will be exactly the same as the various other implementation of > Tyxml (textual (Tyxml.Html), dom/react (Tyxml_js), incremental (JST's > library), react/shared (in eliom)). > Any user that is familiar with one of those API will be able to pick up > the others extremely easily. > > Currently, in your API, you implemented 3 elements: div, input, span. > You'll have to build all of the others by hand. You don't even have > attributes, only the underlying primitives. Tyxml provides a nice API with > sum types and correct types for all HTML5 attributes. > > Finally, you get a syntax extension that takes the usual HTML syntax and > generates the appropriate combinator calls. You don't have to use it, but > some users want to. :) > > Of course, there is a price to pay, you need to implement Tyxml's > Xml_sigs.T. I believe it's not a high price, although your extra type > parameter makes this kind of things more delicate... > > --94eb2c1913b60438390542eb54f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't have a strong opinion either way, but one poin= t not mentioned about Tyxml is that you get nice auto-completion when combi= ned with merlin. I've been pleased to learn the possible values for som= e attributes while coding without having to reference any documentation.

On Sat, Dec 3,= 2016 at 10:27 AM, Drup <drupyog@zoho.com> wrote:

About Tyxml itself: I think that it addresses a rather different set of iss= ues (ensuring that the DOM is "statically correct" w.r.t. definit= ion of HTML5/SVG).=C2=A0 We haven't identified those issues as being re= levant for us, i.e. we have never hit a bug related to breaking such validi= ty constraints, and the lack of static typing does not seem to make refacto= ring UI code more difficult or fragile; so it's not clear to us that ad= ding more static typing here would help.=C2=A0 If we tried to combine it wi= th our vdom approach, it would probably add some noise, since the vdom type= would receive extra type parameters, which would be visible in the interfa= ce of all components exposing "view" functions.

 Tyxml is not only about type-safety. It's about providing an exhaustive= , consistent and convenient HTML5 API for your users.

Tyxml also gives you combinators covering the complete HTML5 surface API. T= his API will be exactly the same as the various other implementation of Tyx= ml (textual (Tyxml.Html), dom/react (Tyxml_js), incremental (JST's libr= ary), react/shared (in eliom)).
Any user that is familiar with one of those API will be able to pick up the= others extremely easily.

Currently, in your API, you implemented 3 elements: div, input, span. You&#= 39;ll have to build all of the others by hand. You don't even have attr= ibutes, only the underlying primitives. Tyxml provides a nice API with sum = types and correct types for all HTML5 attributes.

Finally, you get a syntax extension that takes the usual HTML syntax and ge= nerates the appropriate combinator calls. You don't have to use it, but= some users want to. :)

Of course, there is a price to pay, you need to implement Tyxml's Xml_s= igs.T. I believe it's not a high price, although your extra type parame= ter makes this kind of things more delicate...


--94eb2c1913b60438390542eb54f7--