Isomorphic App: Reason Native vs. BuckleScript on the Server


#1

I’m diving head-on into the Reason ecosystem, and really enjoying it so far. To start, I’m building a small full-stack web application that I’ve wanted to build for some time so that I can learn via a practical application. I want to use Reason for the frontend and backend. My question / topic is this:

There seems to be a pretty big disconnect between Reason on the JS platform via BuckleScript and Reason Native. For example, incompatible build systems (bsb vs. esy) and test runners (a JS test runner, i.e. Jest vs. Rely). I understand it’s early days for Reason Native, and Reason as a whole really. But for my application where I’m trying to have isomorphic Reason code, Reason Native seems like the wrong choice for the backend. I’m simply using Express via bs-express on the backend, and I’m able to share code freely between the front and backends. This is important to me architecturally, as I’m experimenting with architectures that exploit this ability to share code.

I wanted to look into Reason Native for the server, but it seems much easier to just double-down on JS as the platform for hosing Reason. So how much is the community focusing on Native, and what’s the main use case for Native? Should we be making the JS Reason ecosystem more mature before focusing on Native? How do we feel about Reason-on-JS being the main platform for now?


#2

Reason on Node is fine–I’ve heard of at least @splodingsocks using it in production. I’m sure there are others. Check out his Egghead courses (the latest ones): https://egghead.io/search?query=murphy%20randle#

Reason web frameworks on native will happen–it’s a matter of time. The native target is just too enticing to remain unexplored for long. In fact various people are exploring it now. Check out the https://github.com/reason-native-web/morph framework by @ulrikstrid .

To give you the full picture though I should mention the precursor to isomorphic Reason, which is the venerable Ocsigen web framework: https://ocsigen.org/home/intro.html . Not that you should necessarily start with this–it’s using the older OCaml-JS compiler, js_of_ocaml, not BuckleScript. They each have their strengths and weaknesses. This is just to give you an idea that there are existing options out there.


#3

There is an excellent talk by @sgrove about the challenges of building a web application server in reason-native. https://www.youtube.com/watch?v=Lv2QCq6ZBPs

I have a simple Express-based Reason server running in production and it has allowed me to share a large amount of code on both browser and server. Also for most web-related needs there is an npm library. This is much low-risk at the moment compared to starting with native Reason.


#4

Yea, it seems like the path of least resistance is sticking with Bucklescript and JS as the execution platform for now. The performance is already quite good, though I do recognize that the performance benefits of compiling to native are surely enticing.

But the developer ergonomics that come with piggy-backing off of the JS ecosystem are too great to ignore right now I think. It’s great that I can easily write my own JS wrappers if need be. The JS interop is fairly seamless.


#5

I’d be interested in reading about your choice of bindings/libraries and what you liked/didn’t like about them. I’ve been on a similar journey recently but am struggling to find Postgres bindings for the backend.