> I suppose you desugar to a set of combinators, but you don't really expose those. Why ?
Why indeed. I personally find these "HTML in a programming language" tools pretty unappealing, because you have to give up all the normal tools of the programming language while using them [1].
Whereas you can usually write a really simple internal DSL to describe HTML that is as clear and concise as HTML, while being as convenient and powerful as the programming language. My quick and dirty efforts at this usually end up looking something like this:
html(
head(
title("My First Page")),
body(
h1("Welcome"),
p($("Made by "), a(href(), $("Tom"))),
userIsOldSchool()
? p("Bring back HTML 3.2!")
: div("Made with HTML 5.")))
The typed-html crate has an object model like this underneath, but doesn't, AFAICS, expose it.
[1] With the honourable exception of ScalaTags, which i still wouldn't touch with a bargepole
Yes, that's why in Tyxml, we have a set of combinators and an HTML-like syntax, and you can compose them arbitrarily with each other. This way, you can use the HTML syntax (and c/c internet snipets) but still enjoy all the cool functional idioms.
- How compositional it is ? I have find that some of the HTML properties are very hard to verify in a compositional way, see https://github.com/ocsigen/tyxml/issues/175
- How do you handle the "subtyping" aspect that is intrinsic to HTML ? Or phrased in another way: what's your type encoding ? :)
- I suppose you desugar to a set of combinators, but you don't really expose those. Why ?
[1]: https://github.com/ocsigen/tyxml/