I am curious how the various syntaxes are in use in the community. So I thought I’d ask the community. The following poll allows selecting one or more options. Select all that apply.
0 voters
Obviously this is the ReScript forum, but if anybody who’s working on ReasonML syntax (actually really I guess I mean a ReScript/bucklescript fork supporting both backends – I’m not sure whether anybody is still doing that) is interested and reading this: I just voted “no” to “Planning to use ReasonML” syntax – but I’m not planning not to use it either, if that makes sense: I understand ReScript’s focus on the web platform, but I would also still love to use something that allowed me to do native code and web in the same language, if it were supported sufficiently well. (I do know about js_of_ocaml and may use it some time, it’s great but of course the JS output isn’t as amazing as ReScript)
In case it helps–I wrote down some notes on the various use cases: https://dev.to/yawaramin/how-does-rescript-affect-me-1ja
That’s exactly why we’re on OCaml for both. OCaml as a syntax is very likely going to remain stable in the future and has demonstrated 20+year backwards compatibility, so it’s the safest investment for us. I too prefer ReScript’s JS output so I hope its OCaml input support doesn’t get phased out any more than it already has (undocumented but fully functional if you figure out how to use the annotations on your own, different placements in ReScript vs OCaml).
Aren’t all such details effectively documented via running refmt to convert ReScript to OCaml still? Or has refmt lost the ability to convert in that direction already? (sorry if refmt has been renamed too)
Refmt is specifically for ReasonML. ReScript does ship with ReasonML, but it can only convert between OCaml and ReasonML syntax. ReScript uses bsc to convert from ReasonML to ReScript syntax–check the migration guide.
There is no tool to directly convert between OCaml and ReScript. Even if there were, there are more subtle breakages between the two, e.g. ReScript (the compiler) now parses the @@deriving attribute, so valid OCaml code which uses it is most likely not valid ReScript code.
So long as ReScript itself (and the standard library in particular) is written in OCaml, I think you’re safe.
ReScript syntax isn’t an external binary as ReasonML syntax is (refmt). It’s integrated into the core ReScript compiler, so it’s more of an equivalent to OCaml syntax.
Nice summary, thank you.
I wanted to compile OCaml to both native and JavaScript using BuckleScript/ReScript
This is mostly assuming the “run your web server in the same language too” use case I guess.
I want to do something else and the ReScript change affected me
For what it’s worth, in my case I never had the “run web server in same language” use case in mind, partly because I’m working on a local-first thing that wouldn’t really have a traditional server. I’d love to be able to just run parts of my ‘backend’ from the command line or add a native UI without mucking about with serialisation (APIs, graphql, s-expressions, or whatever) – those aren’t made-up requirements by the way, I would claim I have real reasons to be seriously considering command line and native UI as well as web. Also that ‘backend’ will have a node dependency to start with, but I don’t want to depend more than I need to on the JS ecosystem because, though I love the functionality of JS, I don’t yet love its dependency or security story. I’m sure the practical difficulties you mention with web + native with BuckleScript were real, but hey I can still believe “one day my hero will come” 
Maybe later I’ll find my hero existed all along and is called OCaml – but for now I’m very happy to have the great community support that ReScript provides for front end development here – and the incredibly good JS output of course.
For an imagined googler from JS-/TS-world landing here trying to figure out what to use: you should totally use ReScript, none of what I’m talking about above or other posts of mine in this thread applies to you. If you get into it maybe you’ll find reasons you’d like to use OCaml later, but you don’t need to know anything about OCaml to use ReScript. And ReasonML is dead, long live ReScript 
It really is easier for newcomers to grasp now than it was with ReasonML: unlike ReasonML, ReScript is its own language (which just happens to have the same type system as OCaml right now).
If you look carefully, my post doesn’t actually assume that native/JS code sharing is specifically between a web server and client Yes, I mention Ocsigen/Eliom in one place and give an example of my fullstack-reason project in another, but those are just examples. I’m talking about general code sharing between OCaml and ReScript in the same codebase.
I believe you when you say you have good reasons to architect as a CLI and web UI. I just still don’t think that and OCaml/ReasonML native and ReScript mix-and-match project is a good idea, for the reasons given.
I’ve done this in production; there are definitely real world scenarios where it makes sense. I built a library in 2017 with tests that need to load a huge list of files as test data. I chose to compile the tests to native code, partly for speed and partly to see if I could. This placed severe restrictions on the core of the library to make it work for both JS and native, so I wouldn’t recommend it to everyone, but the speed benefit in testing was definitely worth it.
I’ve currently using rescript syntax now for my web at http://alfianguide.netlify.app/ it’s cool.
Obligatory “yep, still using OCaml syntax; nope, I don’t see that changing this decade.”
Too bad the poll already closed.