Dream – Tidy Web Framework for OCaml and ReasonML | Hacker News Reader

Dream – Tidy Web Framework for OCaml and ReasonML

aantron.github.io

136 pointsyawaramin33 comments

Really exciting to watch the developments in OCaml/Reason web frameworks/libraries. I love the language and wish I could use it instead of Ruby for my personal projects at least. Others that have caught my interest are:

Sihl: https://github.com/oxidizing/sihl

ReWeb: https://github.com/yawaramin/re-web/

Of course, if you're interested in OCaml/Reason and don't know about Revery you're missing out.

As follow-on work to Dream, I'd like to take a very hard look at how we do JSON server-side, to really make it much easier. Although this is partially solved by using GraphQL more :) Ideally, in the end, we will have a very fluent server programming experience.

Same goes for SQL prepared statements. I'd like to decrease the amount of boilerplate somewhat, hopefully without resorting to preprocessing.

This is part of the reason I didn't add too many helpers for either JSON or SQL to Dream yet - there seems to be considerable room for improvement here.

See also Opium (vs. Dream): https://discuss.ocaml.org/t/excited-about-dream-web-framewor...

You may have meant this post:

https://discuss.ocaml.org/t/excited-about-dream-web-framewor...

or another in that thread, as the specific one linked doesn't compare Dream with Opium!

Opium itself is found here:

https://github.com/rgrinberg/opium

As an aside I just discovered that Reason (alternative syntax for Ocaml) had been forked by the Bucklescript (Ocaml/Reason to JS compiler) team. The fork is called Rescript and is aims at being a new language and to part with Ocaml. Rescript is also the new name of Bucklescript (compiler) btw. If you don't get any of this, I don't blame you. Here's a thorough explanation of this mess : https://ersin-akinci.medium.com/confused-about-rescript-resc...

The confusing part is that some people decided to name a whole ecosystem project with a name that reads like it's a language (ReasonML) and some other had the wonderful idea to name a compiler that also reads like it's a language (Bucklescript) but to make it more simple they changed the name to... Rescript, but wait now it's also the name of the language. Oh and also Reason calls itself a programming language (when it's just an alternate syntax).

Brilliant.

...and just to make it slightly more confusing, ReScript changed the ReasonML language somewhat, prompting another fork, Melange, which sticks with ReasonML.

In any case, Dream has examples showing full-stack (OCaml client+server) usage with both ReScript and Melange:

- ReScript: https://github.com/aantron/dream/tree/master/example/w-fulls...

- Melange: https://github.com/aantron/dream/tree/master/example/r-fulls...

For good measure, there is also an example with the other OCaml-to-JS compiler...

- Js_of_ocaml: https://github.com/aantron/dream/tree/master/example/w-fulls...

Oh I did not know about Melange, thanks I am so glad somebody made the effort of porting supporting latest reason syntax !

Anecdote: I was all ready to start learning Reason/Rescript, and then I saw the confusing stew of renames and forks. I changed my mind, and I don't plan on touching it until something settles out.

As an outsider with respect to the community, I can't think of a bigger impediment to adoption than a scenario like this. Apart from something catastrophic like a BDFL ghosting or going closed source.

Many people, including me, were pretty bummed out by that whole process. There was a definite dip in activity for a while. I also stayed away, because for me, it was basically more churn at a time when I was already feeling burned out.

I learned from all this, that at least for the near term, OCaml is by far the most stable part of the... OCaml ecosystem :) I'm fine with that, since I started out with OCaml and like it, but I do worry for everyone that prefers JS-like syntax and wants to do a lot of client-side programming.

I'm still confused - is there a set of syntax/language/compilers that will allow me to have one codebase, one syntax, and run the server as native code (possibly with nodejs as an option) - and use same language for the front-end?

As far as I understand it - with ReScript, deploying via ocaml compile to native is not supported - you get nodejs as the server?

> is there a set of syntax/language/compilers that will allow me to have one codebase, one syntax, and run the server as native code (possibly with nodejs as an option) - and use same language for the front-end?

You can use the normal OCaml syntax with the main OCaml compiler and the js_of_ocaml compiler. If you just want something in the ecosystem that's boring and reliable these are almost certainly the way to go.

Agreed on Js_of_ocaml as a stable choice.

However, even Js_of_ocaml is suffering a slight complication :P There is the recent release of Brr https://erratique.ch/software/brr/doc/, a Js_of_ocaml library replacement (i.e. you keep the compiler but use this instead of the library that comes with Js_of_ocaml).

I heard good reviews of Brr, but haven't tried it myself yet. We will probably have a Brr full-stack example in Dream, eventually.

Personally, I currently use

- Dream on the server (an ancient version, didn't have time to keep up with Dream development in my own app!).

- Just plain JS and the JS ecosystem on the client.

- ReScript/Melange for compiling a couple files to JS from OCaml so that they can trivially interop with my mostly-JS client.

Yes. OCaml + all of the 3 OCaml-to-JS compilers support OCaml syntax.

Dream itself demonstrates:

- Server and client both written in Reason, using ocamlc+Melange https://github.com/aantron/dream/tree/master/example/r-fulls...

That example could also have been written in OCaml syntax, because ocamlc (native) and Melange (JS) both support OCaml. However, Reason is nicer if you want to use React with JSX on the client.

- Server and client both written in OCaml, using ocamlc+Js_of_ocaml https://github.com/aantron/dream/tree/master/example/w-fulls...

- The remaining example uses Ocaml on the server and ReScript on the client, using the ReScript compiler. However, you could use OCaml on the client with the ReScript compiler. Just as with Melange, you would lose access to nice JSX syntax https://github.com/aantron/dream/tree/master/example/w-fulls...

It's definitely a lot and not user-friendly to have to decide between all these options, but the community is experimenting greatly right now... so it's good and bad, and that's how it is :/

As for Node.js, using ReScript syntax requires you to use Node.js on the server side, but that is the only coupling. If you write your server side in OCaml or Reason, you can compile it to native code with ocamlc (technically, ocamlopt is the internal command; nobody uses either one directly, but the build system calls them).

EDIT to clarify the last paragraph: the only coupling is that ReScript compiles only to JS. Everything else compiles to both JS and native and by multiple compilers...

I don't understand what an "ecosystem project" even means. Every language has an ecosystem. There isn't a separate name for the ecosystem. Why is there here?

That page doesn’t link to the examples in GitHub whose README [1] is unexpectedly informative, having its own roadmap.

Anyone using this in anger?

[1] https://github.com/aantron/dream/tree/master/example#readme

Probably nobody using this in the community yet, as the project is not yet released (or deliberately announced).

I have some code built against an earlier version of it, but there have been so many changes during development, that the web app that spawned Dream needs to be adapted :)

I’ve been looking for something like this to tempt me away from Flask and get me using an ML-derived language. Best of luck with it!

What a nice surprise! No bloat, no fluff, just bare metal.

I wish this project takes off. I remember how beneficial Sinatra was among the heavy Ruby frameworks.

We need something else than the React / Vue / Svelte triumvirate. Something much simpler. Something which brings back the joy and playfulness in web development.

True but also we end re-inventing wheel as the project grows. After someone we will endup with react built on Dream. All frameworks were born for a reason right?

I'm hoping, praying, and betting that powerful, sound, and elegant type systems will capture and integrate a lot of the boiling-plate frameworkery. Reinventing less and less of the wheel every cycle into oblivion.

What’s wrong with Typescript...? Or even JSdoc. All this for what? Elegance and productivity? Svelte and typescript seem significantly faster to read and write than all the code I’ve seen from all this. And can even leverage the JS ecosystem. I feel like I’m missing the point of all this oCaml stuff, but I would like to understand the appeal.

AFAICT all of these are client-side frameworks. Dream is a server-side framework. I currently write my server with Dream and use regular JS React on the client.

If you glance at most of Dream's examples that serve an interactive client, you will see that they serve JavaScript:

https://github.com/aantron/dream/tree/master/example/k-webso...

You can use anything you want for the client, and I use the JS ecosystem heavily in my own usage.

There are several full-stack OCaml examples, but that's entirely optional:

https://github.com/aantron/dream/tree/master/example#full-st...

As for server-side comparisons, OCaml is much easier for me to work with than, for example, TypeScript for many reasons. The first is that I can compile several hundred OCaml files, in the rare case of a full rebuild, in less time than running tsc incrementally on a small project, resulting in a much better iteration experience.

Typescript is indeed a step in this same direction!, as I see it.

Underneath, Typescript has a goopier type system than OCaml. Formally speaking. Therefore Typescript ends up being less consistent and a less efficient tool for thought ... for me personally.

That's the part underneath. On the surface we can use any syntax we care to.

The Rescript language, formerly known as ReasonML, is a JavaScript-style syntax frontend for the OCaml compiler, plus a backend that compiles to quite readable and fast JavaScript: https://rescript-lang.org/

The end result is a very readable language that feels comfortable. We can quickly write robust programs in it. (There's more inherent robustness than in TypeScript!) It also interoperates very elegantly with the JS ecosystem and runs on JavaScript runtimes.

OCaml code and ReScript language can be transpiled to each other, so depending on how Dream talks to the external world – i.e. what's the shape of the system call interface at the end of Dream's world? - then maybe Dream the OCaml web framework can be used as a JavaScript web framework and run on Node.js. Which is interesting and I want to understand now that I know to ask the question – thanks!

Dream doesn't have much of a system call dependency footprint itself. It's basically just a convention for plugging request -> response functions into a web server. Some of its native dependencies will have to be replaced by Node equivalents. Soon after that, it would be portable to Node.

There is already work underway to port Dream to Mirage, to run in unikernels: https://github.com/aantron/dream/pull/22

Lwt, Dream's promise library, is itself getting ported to run on top of libuv: https://github.com/ocsigen/lwt/issues/813

libuv is, of course, the I/O library that powers Node, so it might be practical to run Dream as a native node module very soon after doing this.

(As an aside, I'm supposed to work on that libuv project, but instead I've been working on Dream :P)

1 part thanks to 1 part kudos. Full glass. For you! This is pretty cool work you're doing!

The creator of React was inspired by ocaml and made Reason I believe.

https://reasonml.github.io/reason-react/

Maybe we should re-explore this guys ideas because he obviously was on to something. The above examples look elegant but I still need to see those real world hairy components to truly judge it.

React was originally written in StandardML.

https://overreacted.io/algebraic-effects-for-the-rest-of-us/ shows how OCaml's influence is part of hooks too.

Unpopular opinion, I seen the results of the frameworks from reasonml. The eco system, no company will want to take the risk of using. Before saying "onivim" is using it, its fast.

I have the nightly of onivim2 and st4. Sublime beats the crap out of it, and onivim2 is starting to show slowness in the UI. VSCode is faster than onivm2, yet it suppose to use reasonml.

My advice, never bet your future and company on this fragmented framework.

finally, some ocaml project has good document!

The documentation is stellar and it makes Dream looks accessible even for a non-ML'er like myself. I also liked how you introduced HTML through preprocessing.

I wish F# would take a similar approach. Nothing seems to come close.

OCaml on Windows seem to only run under Msys or cygwin. Do most OCaml devs develop on Linux?

OCaml actually runs natively on Windows, it's just that for development some Unix-like environment is needed, because many packages have a habit of accidentally pulling in and using convenient Unix-isms like bash and grep. Nowadays WSL is used by many, and it works great.

But the toolchain can produce applications that run on Windows without any special support, and people have been shipping OCaml apps on Windows for a long time. E.g. the Unison file sync utility, the MLDonkey file share program.

I do everything under WSL on Windows. So, still effectively Linux :)

As for Cygwin, that was my choice for a long time when I started with OCaml.

For building fully-native Windows apps, I've used https://fdopen.github.io/opam-repository-mingw/installation/. However, it still requires a Cygwin environment to run in, because, as yawaramin mentioned, much of the OCaml ecosystem assumes Linux-like tools during build. So, effectively, the Windows setup looks a bit like cross-compilation, where your build environment is Cygwin, but the output is non-Cygwin full-native Windows binaries.

The compiler itself and core tools like Dune don't assume Linux tools and are portable. It's many of the packages among the rest of what is there that trigger the Linux tools dependency.

Reply on news.ycombinator.com