dream-html VS reason

FOR some time now, I have been maintaining an OCaml library called dream-html. This library is primarily intended to render correctly-constructed HTML, SVG, and MathML. Recently, I added the ability to render well-formed XML markup, which has slightly different rules than HTML. For example, in HTML if you want to write an empty div tag, you do:

htmx is a JavaScript library which interprets a set of HTML attributes and JavaScript events. It doesn't have anything to do with static typing. However, it's fairly easy to add a statically-typed layer on top of it eg https://github.com/yawaramin/dream-html

There is some truth to this. Imho the next level of htmx is unlocked when you componentize everything like a React app...but with nested routes corresponding to nested components like a Remix app...and using an HTML generation DSL embedded directly in your language, so HTML becomes a first-class citizen of your language's constructs, rather than a templated afterthought. I have a demo of this: https://github.com/yawaramin/dream-html/tree/todoapp/app

Nowadays I highly recommend HTML embedding libraries directly in the programming language. E.g. ScalaTags https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html

Yes, you give up the ability of designers and frontend-only people to easily work with the HTML templates. But in exchange you get quite a lot.

I found your article very informative and it matches up quite a bit with my own thinking about HTML generation. In fact it looks like we independently arrived at pretty much the same conclusions. A lot of the issues you raise are the impetus behind the way I designed my HTML-generation DSL: https://github.com/yawaramin/dream-html

I am developing an HTML generation library on top of Dream, to have great support in the language including htmx support: https://yawaramin.github.io/dream-html/dream-html/Dream_html/index.html

Look at this code which prints out an HTML tag: https://github.com/yawaramin/dream-html/blob/main/lib/dream_...

Initially you might think generating HTML tags from data structures in code should be a simple matter. But there are complexities--some tags are defined as having no child tags, others do. Some tags are purely character data (unstructured text), not structured data. Some are just comments. We need a way to compose multiple tags together into a single 'virtual' tag for flexible HTML generation. All these conditions can be pretty hard to keep track of--unless your compiler does exhaustiveness checking. Then the compiler will tell you if you missed any cases.

In the example above I didn't make any manual effort to cover all the cases, I simple listed out the cases I wanted to handle in order. The compiler made sure that I didn't miss any.

I wish they would update their blog![0] The last post is from Aug. 2018, which definitely gives the impression that the project is dead.

But it's not dead, if you look at their GitHub.[1]

[0] https://reasonml.github.io/blog/

[1] https://github.com/reasonml/reason

OCaml makes so much sense to me -- it's just a shame that the syntax has some weird decisions.

I wish ReasonML (https://reasonml.github.io/) would come back -- it's a new syntax for the same language, kind of an Elixir/Erlang thing.

Ocaml is still a wonderful language if you want to look into it, and Reason is still going strong as an alternate syntax for OCaml. With either OCaml or Reason you can compile to native code, or use the continuation of BuckleScript now called Melange.

Hey HN, at Ahrefs we have been working on an online book that hopefully helps React developers get up and running with Melange, an OCaml to JavaScript compiler. You can read more about Melange here: https://melange.re/.

There are still a few chapters that we'd like to add before considering it "complete", but it might be already helpful for some folks out there, that's why we decided to publish it early.

The book uses Reason syntax to implement React components using ReasonReact components. You can read more about both in:

https://reasonml.github.io/

ReScript is "Fast, Simple, Fully Typed JavaScript from the Future". What that means is that ReScript has a lightning fast compiler, an easy to learn JS like syntax, strong static types, with amazing features like pattern matching and variant types. Until 2020 it was called "BuckleScript" and is closely related to ReasonML.

This tracks with how I've seen "normal" languages converge on similar, flawed imitations of better type systems through tools and repurposed syntax. Thank you for confirming.

Do you have any recommendations or warnings regarding general languages which reach in the opposite direction? Reason[1] and F#[2] are both examples: they attach pre-existing ecosystems and compile-for-$PLATFORM tools to OCaml-like typing.

OCaml itself is also intriguing for personal projects. However, I'm worried the "GPL" in its standard library's LGPL license might scare people despite both the linking exception and Jane Street's MIT alternative.

1. https://reasonml.github.io/

ReasonML purely as a syntax layer on top of OCaml is still being updated and released[1]. Incidentally, I'm one of the maintainers of that project too :-)

With this Melange release, we're hoping to somewhat revive ReasonML and channel some folks back to the community from the perspective of a vertically integrated platform that has seen major investment in the past few years.

[1]: https://github.com/reasonml/reason