4 ms·

I understand what you're saying. Many native OCaml libs are not portable to JS, and you definitely can't port a JS lib to OCaml with the current toolset, which

I understand what you're saying. Many native OCaml libs are not portable to JS, and you definitely can't port a JS lib to OCaml with the current toolset, which prevents the dream of being able to not care at all about runtime. It's the same dream I've been chasing on the Clojure(Script) side lately as well. 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'd love to use the nice ReasonReact component abstraction, but it is not at all portable to native. 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.

kbenson 9y ago
> 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. That was the conclusion I came to as well, but I decided it wasn't worth doing so at this stage. I think eventually the ReasonML ecosystem will grow enough to make this much easier. It's nice that you can use Ocaml libs and Js libs in instances, but I think there are use cases where people mistake can for sufficient, when in those cases it's not. Ideally this would be solved by pushing Ocaml libs towards JS, but I'm not sure how much attention Ocaml has gotten with respect to we stacks (even the lower end of web stacks). It's unclear to me whether high quality libs exist to push towards JS to all the needs that exist in that space.

kbenson 9y ago

> 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. That was the conclusion I came to as well, but I decided it wasn't worth doing so at this stage. I think eventually the ReasonML ecosystem will grow enough to make this much easier. It's nice that you can use Ocaml libs and Js libs in instances, but I think there are use cases where people mistake can for sufficient, when in those cases it's not. Ideally this would be solved by pushing Ocaml libs towards JS, but I'm not sure how much attention Ocaml has gotten with respect to we stacks (even the lower end of web stacks). It's unclear to me whether high quality libs exist to push towards JS to all the needs that exist in that space.