<story><title>Reason ML toolchain</title><url>https://khoanguyen.me/reasonml-toolchain/</url></story><parent_chain><item><author>kbenson</author><text>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.&lt;p&gt;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&amp;#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&amp;#x2F;framework?  There&amp;#x27;s a lot written in JS, but you&amp;#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.&lt;p&gt;What it seems to come down to is that Reason needs a whole lot more software written in Reason so it&amp;#x27;s more flexible.  Being able to use Ocaml and JS packages is a feature and liberating, nut &lt;i&gt;having&lt;/i&gt; 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&amp;#x27;t deliver.  &lt;i&gt;Yet&lt;/i&gt;.</text></item></parent_chain><comment><author>lilactown</author><text>I understand what you&amp;#x27;re saying. Many native OCaml libs are not portable to JS, and you definitely can&amp;#x27;t port a JS lib to OCaml with the current toolset, which prevents the &lt;i&gt;dream&lt;/i&gt; of being able to not care at all about runtime. It&amp;#x27;s the same dream I&amp;#x27;ve been chasing on the Clojure(Script) side lately as well.&lt;p&gt;I believe you can get close in ReasonML by making a clear distinction between client (JS) and server (native), and then maintaining a common module of business logic and utilities that you would want to share between the two. This works well up to the point where you want to server-render some HTML, at which point you become sad because you&amp;#x27;d love to use the nice ReasonReact component abstraction, but it is not at all portable to native.&lt;p&gt;Jared Forsythe has been doing a lot of work on making portable applications and libraries in ReasonML, and I do believe that the native compilation story will receive enough love that more people start taking it more seriously - right now the majority of time + energy of the ReasonML team seems to be focusing on honing JS application development, so most of the community is orbiting that use case.</text></comment>
<story><title>Reason ML toolchain</title><url>https://khoanguyen.me/reasonml-toolchain/</url></story><parent_chain><item><author>kbenson</author><text>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.&lt;p&gt;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&amp;#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&amp;#x2F;framework?  There&amp;#x27;s a lot written in JS, but you&amp;#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.&lt;p&gt;What it seems to come down to is that Reason needs a whole lot more software written in Reason so it&amp;#x27;s more flexible.  Being able to use Ocaml and JS packages is a feature and liberating, nut &lt;i&gt;having&lt;/i&gt; 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&amp;#x27;t deliver.  &lt;i&gt;Yet&lt;/i&gt;.</text></item></parent_chain><comment><author>thangngoc89</author><text>Hey author here,&lt;p&gt;I think I failed to explain about this in the article. OCaml and ReasonML is the SAME language with different syntax. You don&amp;#x27;t need to worry whether the library is written in OCaml or ReasonML as long as your build tool support both ReasonML and OCaml.</text></comment>