Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. 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.
> Someone will have to explain why I might pick ReasonML over Elm
* 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.
Elm is cool, the BDFL seems like a great guy, but he's a bottleneck and the community is too small. I developed our internal Dashboard using Elm and we have already end-of-lifed it primarily for this reason. I think it's always going to be a niche product and I can't justify betting my business on that. Other larger communities are going to take these ideas and execute on them better.
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.
ReasonML has a much more advanced module system via Functors. As far as I know Elm has nothing like this. Despite a fair few arguments over incorporating type classes into Elm, the creator is pretty dead set against the idea.
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.
Agreed, I love Elm but the lack of documentation was a pretty big hurdle for me. Especially because I came from using elixir/phoenix on the backend which I found had excellent guides and docs (for language, framework and most packages).
No runtime. ReasonML is a language that has decent interop capabilities with javascript through the bucklescript compiler. You can use it to write drop in ready code segments into an existing codebase.
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.
I ran into this question a lot when speaking about ReasonML, and am quite a fan of Elm as well. I wanted to address it holistically, so (if you'll forgive the shameless plug), I did a talk on some of the motivations of ReasonML (as I see them) and a high-level comparison to Elm here https://vimeo.com/242081961
Having recently started learning Elm, I am considering switching over to ReasonML. Elm's architecture is really great for front end development and the error messages are awesome, but the ecosystem is in its infancy, and development is driven by just one guy. I've seen a lot of open PRs and issues on Github with genuinely great features, but haven't been merged in yet.
ReasonML's documentation also seems better (especially for a functional programming newbie)
I am not advocating anything in particular as I am in the process of choosing the next language to learn. That said, I have watched some talks by Cheng Lou and some others about ReasonML.
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.
> why I might pick ReasonML over Elm for front-end development?
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]
I would also like to know if ReasonML makes some "guarantees" of zero runtime errors like Elm does. That's one reason what makes Elm attractive to me, though I haven't programmed much in it.
It does not. sgrove posted this above https://vimeo.com/242081961 which is a talk he gave. Ended up watching it all the way through and came away being happier with ReasonML than I was before (eh, preconceptions because Facebook). It is a good talk, but please ignore the graphs because they aren't scientific in any sense of the word - more emotional appeal statements.
Actually, the Reason team is basically made up of experienced OCamlers who wanted to attract the JavaScript community and figured that a familiar syntax would help a lot (I think they were right). See https://reasonml.github.io/docs/en/what-and-why.html#why-rea... for more details.
