Of course, if you're interested in OCaml/Reason and don't know about Revery you're missing out.
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.
or another in that thread, as the specific one linked doesn't compare Dream with Opium!
Opium itself is found here:
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).
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...
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.
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.
As far as I understand it - with ReScript, deploying via ocaml compile to native is not supported - you get nodejs as the server?
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.
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.
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...
Anyone using this in anger?
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 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.
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.
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:
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.
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.
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)
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.
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?
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.
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.