* bigger team (Elm the lang itself is almost a one man show)
* openly developed (Elm's dev't is in private, for now at least)
* interop with JS is easier
* great interop with React
* has a company behind it (FB), who uses it in production (messenger.com)
* already works on the server (with Node and with experimental native compilation (bsb-native))
* server-side native compilation is within the vision the core team (not so much with Elm)
* a lib exists for The Elm Architecture (TEA), see the bucklescript-tea package
* JS'ish (C'ish) syntax (Elm has an ML like syntax) -- this may or may not be your thing, I think it makes FP more accessible
* not pure functional (like Elm), thus allows mutation and side effects -- this may or may not be your thing, it makes interop with JS easier but comes with less strong safety guarantees
> Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible.
Elm's community is great, but probably smaller than ReasonML's community in the long run, as I expect FB to use it a lot internally and thus has a great patron. Also, most big tech has their own language: Apple/Swift(ObjC), Google/Go(Dart), Mozilla/Rust, FB/Reason. I think it is the only language that potentially facilitate both FE, mobile and server-side dev't. It's a very interesting pick at this point.
> ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.
Yes. And to me this does not sound bad. They took OCaml, and BuckleScript, then added a new syntax, some tooling and libraries. They positioned a language that ticks a lot of boxes in a very short time, and since it has free interop with OCaml it comes with quite a strong lib ecosys for native (server-side) dev't.
The only way I see this changing is if Evan massively delegates responsibility, and I just don't see that happening. Elm is cool because it's small and tightly controlled, but that also limits its viability and growth potential.
This does make Elm a lot more approachable, but after a while can feel quite restrictive.
There is bucklescript-tea, which is the Elm architecture in for Bucklescript (and thus also Reason). It is pretty much an exact match, so technically there isn't really anything you are missing out on by going with Reason. In reality the Elm community is more mature which means there is more documentation and libraries available. However bucklescript does interface to javascript a LOT easier - which does open up a much wider ecosystem of javascript libraries.
There's some excellent libraries but the Elm documentation is terrible compared to Reason.
Hello world in ReasonML will get you a single line javascript output. Last I looked, the Elm bundle is in the 10s of kbs for something like that because you get the whole architecture.
Add is ReasonReact and it's a little more comparable obviously.
ReasonML's documentation also seems better (especially for a functional programming newbie)
Elm is just "Elm"... that isn't a bad thing and it seems like it is more mature at the moment.
ReasonML is Ocaml that plays nice on any screen anywhere thanks to Bucklescript. It also plays nice as a systems language. That is, unikernels... I am not even sure what they are, but they sound awesome and I want that.
Even just Dr Rauschmayer's blog and now this book blow away anything I've ever found in the Elm ecosystem.
I think ReasonML is better compared to TypeScript and Flow, rather than Elm.
Elm is pure, but I would still want to write my JS ports in a statically typed language. I would use TypeScript, but here is the project that let you use ReasonML[1]