Oooh that's a very hard question :p I'd need to sit down a bit to answer it, to be honest it could almost be its own article. They both try to accomplish the same things through very different means with very different backings (Facebook versus literally one person).

I can already tell you that ReasonML definitely has my preference these days over Elm, for the simple fact that I can keep using React with it. I love React, it's one of my favorite frameworks. If you're already familiar with it you're 50% of the way there to learn ReasonReact, whereas with Elm it really lives in its own little universe that you need to get familiar with from scratch.

I find ReasonReact's underbelly a bit messier, and the compiler is not as good nor as clear as Elm's though. And the whole OCaml layer brings some chaos too, like the multiple standard libraries available in ReasonML (OCaml's, ReasonML's, etc) which can all be very confusing when you begin.

So, I wouldn't really know what to tell you, it depends wildly of your experience, what you like, what you're looking for in the language and so on. I'd definitely recommend to give both a shot and see what you like as they're both great languages to me, even if ReasonML has my preference.

> the compiler is not as good nor as clear as Elm's though

in the article, you mentioned:

> the compiler is one of the best compilers I’ve ever seen and will not compile if it detects that your code is not sound.

It seems like your're judging the entirety of the compiler just on it's user displayed error messages?

Indeed sorry that's badly worded, both compilers are very good, I meant more the UX around compilation in general as I'm not apt to judge the compilers themselves.

To me the biggest difference is that [Reason]React focuses on components which encapsulate state, while Elm focuses on data structures and pure stateless functions. Both approaches have pros and cons. You can design a [Reason]React app similar to an Elm app, if you use pure stateless components exclusively and handle your state with few reducers, but you won't get the same smooth experience which you get with Elm. I still favor React though. React's component interface adds some friction and complexity, but it's also a nice abstraction which helps a lot with code sharing, especially when sharing with third parties. Thus the striving ecosystem (UI frameworks, UI builders, etc.) in React.

I made a round trip over the last years from React/TS to Elm to ReasonReact back to React/TS. React/TS is the least attractive, but it's the one I get most done with. Plus the situation in React has gotten much better since Hooks, PureComponents, Context API. I'm glad the mess with class components is finally over.