Hi I'm Jordan and I work on Reason(http://facebook.github.io/reason http://facebook.github.io/reason), and previously worked on ReactJS(https://facebook.github.

Hi I'm Jordan and I work on Reason(http://facebook.github.io/reason http://facebook.github.io/reason), and previously worked on ReactJS(https://facebook.github.io/react/ https://facebook.github.io/react/), so this touches on a lot of things that are of interest to me. We currently use the OCaml language with the Reason frontend, for UI development, and use BuckleScript for compiling it to JavaScript. To some it might seem like this JSCaml project might be "backwards" in that it compiles from JS to OCaml, instead of the other way around, but both of these share one important / valuable thing in common - they use exactly one memory system, allocator, collector between two different languages. This is very different than embedding a separate VM/language/allocator as a library inside of another language runtime. If you've ever tried to bridge two completely different memory systems together without introducing leaks, you'll quickly realize why JSCaml gets the most important thing right, even if it is missing some JS language features - those missing features can be added over time, whereas unifying two inherently incompatible memory systems can be bankruptingly expensive. Seamless memory lifetime interop without leaked cycles is essential for incrementally moving a code base from one language to the other. In browsers, that means your only hope is to target semi-idiomatic JavaScript if you want to incrementally move a large JavaScript system to another language. Wasm is currently great for whole-program rewrites from scratch, not incrementally moving over. That's why BuckleScript has been so helpful. When not running in the browser, you have many more options, and if given the choice between running Reason/OCaml in a JavaScript VM, vs. running JavaScript in an ocamlopt runtime, the later offers many compelling advantages. 1. The ocamlopt runtime allows languages with sound static guarantees to take advantage of those guarantees to emit more efficient machine code, reaching the language's full potential. JavaScript will have to go through all the same dynamic (costly) checks due to its language complexity - at least for object property/method dispatch, but why should that mean that OCaml should have to as well? By running inside of the ocamlopt runtime, it can share one memory system without being limited by an unrelated dynamic language's weaknesses. 2. Depending on the approach, the emitted JavaScript might be able to take advantage of many of ocamlopt's ahead of time optimizations to reduce allocations, and inline function calls (F-lambda for example) without having to wait for the JIT to reach many of the same conclusions (which slows down startup time). 3. Even if the JavaScript compiled to ocamlopt runtime doesn't demonstrate as much throughput as it would with a JIT (once you wait for it to warm up of course), the approach of JSCaml allows you to seamlessly break off bottlenecks and write them in Reason/OCaml which could end up running even faster than JS with a JIT once warmed up (and without having to wait for the slow JS VM's startup initialization). I'm sure there's a ton of work left on JSCaml until you can one-click deploy your JS programs and see performance wins, but I'm very interested in this general direction, as it has many uniquely compelling advantages that stand to help move the JavaScript ecosystem forward.