ReasonML is, as it has always been, a 100% syntax map to OCaml. It will always be that, but moving forward it will be nothing more than that. Compiling future ReasonML versions to JS will require js_of_ocaml.
The success of BuckleScript meant that a _lot_ of people used what they thought was ReasonML but it was really ReasonML+BuckleScript. This lead to a ton of confusion the moment newcomers realised they needed a second website to look up APIs.
ReScript includes a snapshot version of ReasonML for backwards compatibility, but it will never be upgraded.
The future of ReasonML is likely slow and steady progress, potentially fading into obscurity as the target audience is now very small (OCaml developers who don't like OCaml syntax).
ReasonML isn't dead, but the way I heard the story it has always been a spare time project not a properly funded FB team. There was just enough spare time early on to get the community excited.
From the same source, I heard ReScript does have funding behind it.
We aren't sure when we will be able to open source the new model, and we are still using Reason syntax with the ReScript compiler, but we will transition to ReScript syntax eventually.
IMO this isn't about whether ReScript wants to upstream their changes, it's a combination of things:
- Reason+BuckleScript was confusing at best, having two websites and different release schedules.
- Reason's goal is to be a 100% mapped syntax for OCaml. This does not mesh well with the goal of producing readable JS, so ReScript will probably end up as a subset of OCaml features.
- Reason syntax changes apparently caused grief when applied to BuckleScript. This one was never very clear, but regardless now that the syntax is in-house the ReScript team can be more responsive with it.
The problem with this transition is that it was dropped on the community in an unfinished state and BuckleScript was retired completely. The goals of the change are, I think, mostly reasonable.
I have no skin in the game w.r.t to OCaml/Reason/etc. I do wish compile-to-JS languages would give up on the readable Javascript thing. I think ClojureScript nailed it with their reliance on Google Closure's aggressive optimization mode __because__ it produces obfuscated, highly optimized output.
Purescript also shares this goal, and it is a bummer, performance-wise, in older browsers that don't handle currying and various other "readable" representations well.
Worse still, if your target output is readable, then someone might start touching the compiled runtime objects with Javascript and then... god help you as you watch the guarantees of your fancy type system unravel before your very eyes.
"readable output" isn't really about being human-readable, except in unrealistic example cases. The bigger benefit is shared data types; this helps immensely with JS interop.
I feel like the dev team is using "readable output" to mean both "human-readable" and "shared data types" depending on the situation. And it creates a lot of confusion.
Spyder81 is partly right, 'readable' doesn't mean 'human-readable' per se, it means rather that the compiler tries very hard to produce output JS that looks like idiomatic, hand-written JS. This means things like:
- Uncurrying functions
- Compiling OCaml modules to idiomatic JavaScript objects
- Compiling OCaml record values to idiomatic JavaScript objects
- Compiling tail recursion to idiomatic while loops
- And so on.
> someone might start touching the compiled runtime objects with Javascript and then... god help you as you watch the guarantees of your fancy type system unravel before your very eyes.
That's exactly what genType is for--it produces JavaScript, TypeScript, and Flow interfaces for ReScript output code so that people in the JS world can consume it transparently.
You might have been able to use the same syntax before, but writing code for Reason native was already very different to writing Reason+BuckleScript for the browser. This just formalises the split.
To write the same code for both front and back end js_of_ocaml has been the standard since long before Reason came along, and it works just fine with Reason native.
The standard compiler can do a cold compile of a single file in milliseconds. When the compiler is that fast you _can_ just wrap it up and it'll still be faster than TypeScript.
But to answer your actual question:
The current standard (reason-language-server) does simply wrap the compiler, and it's more than fast enough, but the community is working on a new merlin-based language server (ocaml-lsp) which does support partial compilation.
