Reason ML toolchain
I was looking into ReasonML a few weeks back because the promise of whatr it offered was so great.  Write in one language, and run on the server and on the client, but allow the server to be compiled natively for speed.  This really appealed to me, especially because there are some times that I really wish I had some utilities I had written on the back-end available on the front end.<p>Unfortunately, what you appear to have currently is that a lot of the tools and utilities you would want to use in ReasonML are written in either JS of Ocaml, and reply on the interop when you target that platform.  Want an ORM?  There&#x27;s a couple, but they are all targeted at Ocaml, so you either compile to native and link or try to port the Ocaml source of it to ReasonML (maybe automatically?) and maintain it.  Want a web router&#x2F;framework?  There&#x27;s a lot written in JS, but you&#x27;ll be configuring and writing some JS most likely to get it to work, and no compiling that natively.  This is a recurring theme.  Most robust larger packages are in one language or another, which causes problems for anyone wanting to leverage the inherent advantages of both target formats.<p>What it seems to come down to is that Reason needs a whole lot more software written in Reason so it&#x27;s more flexible.  Being able to use Ocaml and JS packages is a feature and liberating, nut <i>having</i> to use Ocaml or JS packages ends up putting constraints on your project.  ReasonML has a lot of promise, but at least for what I was excited about, it can&#x27;t deliver.  <i>Yet</i>.