Is that crazy? Maybe, but:
- I’d like to be able to run my ‘backend’ as fast native code
- I’d like to use OCaml libraries and learn about OCaml language features
- I’d like to use jsoo to deploy the OCaml backend on the web
- I’d like to write a UI for that code using ReScript
“Backend” may be not the best word: perhaps “model” is better because I don’t intend running most of it on a server – similar to what Thomas Leonard did with his inspiring CueKeeper.
Perhaps somebody out there is simply doing this by writing ReScript bindings to jsoo-generated JS?
Perhaps somebody is also exposing an OCaml language-agnostic API itself running in-browser over graphql or S-expressions or similar and consuming that from ReScript? For projects that can run fully in-browser like CueKeeper this would seems especially awkward since everything would run in a single browser process, in two languages with very similar semantics, yet constantly dealing with extra
serialization admin.
In my dream, somebody creates a tool (I don’t have the skills!) which, given some restricted .mli subset perhaps, would generate both ReScript bindings to jsoo-generated JS, and whatever bindings jsoo needs to cleanly expose its JS to other JS code. Just a little wish for somebody’s Saturday afternoon 
Seriously, of course anything like this would be a bigger project than that – but I do wonder if it’s quite as big as it first appears: it seems that with appropriate restrictions to reduce the interface to a conservatively-defined stable subset of the two languages, the implementation could “live” on the OCaml/jsoo side, without needing to introduce a whole new compiler fork, let alone one that understands everything about both ReScript and OCaml?
Perhaps the answer is still “use Reason”, but my judgement for now (based on not much knowledge) is that I don’t want to be in such a small crowd. I don’t think writing bindings puts one quite in that same position in practice?