antron-prime

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.

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...

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)

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.

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.

...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...

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 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.

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 :)