I was just hoping that some people who might have made this decision could speak a bit about their reasoning behind the decision. Specifically, if you could mention your use-case, as well as what language features you needed (or wished for) and finally the pros/cons you used to make your decision.
I'd choose Elm but that's because I have the most experience with it. It's closed ecosystem (interop with JS libraries is more ceremonious than with other alternatives here), but it's wonderful (compiler-as-assistant, elm-format etc.). Honestly writing Elm just makes me happy :)<p>ClojureScript is nice but my last experience with was before the Spec arrived. I've had a Slack bot running in Clojure, didn't look at it for three months and when I needed to fix a bug, I couldn't remember what shape the data was in, and kind of burned out trying to get back into it. That made me try something strongly statically typed. I reckon my experience would be different with Spec now.<p>Purescript is like Elm, just with less hand-holding and more advanced everything. Might suit you if you like Haskell?<p>No experience with ReasonML.<p>Edit: speaking more generally, I'd take anything with algebraic datatypes. Thankfully most modern languages do have them nowadays.
ClojureScript is mature, has great tooling, and embraces the host platform making interop mostly painless. My team has been using it for nearly four years now, and we're very happy with it.<p>This workshop runs through all the basics of building a small app from start to finish
<a href="https://github.com/ClojureTO/JS-Workshop" rel="nofollow">https://github.com/ClojureTO/JS-Workshop</a>
I'm working on a few Elm sideprojects and am having a blast. The IDE integration (elm-format, type checking hints) is a miracle. the `style-elements` library is an absolutely wonderful DSL for writing predictable/flexible/fluid/decoupled layout code. And the file sizes with 0.19 are miniscule (my app previously minified down to 100kb, but now it is about 20kb)
I wanted algebraic datatypes, purity, safe JS interop. Elm satisfied all of those nicely. I've spent a year on an Elm side project and a few months on production Elm and am more convinced than ever that it's the language/ecosystem I prefer for front-end.
You may want to take a look at Fable[0] if you haven't seen it yet. I'm considering using it for an internal tooling work project in the near future.<p>[0] <a href="http://fable.io/" rel="nofollow">http://fable.io/</a>
For side-projects I like to play around with PureScript.<p>Mostly because I really like things like simple-json, where it can parse a json string based just on the type you are expecting.<p>It looks powerful, and i.e. Halogen framework has decent examples, documentation, and seems to be designed in a way, that provides you plenty escape-hatches for your components, once you need to do something more complicated.<p>If you need even more escape hatches, the FFI is quite un-assuming.<p>On the other hand, I haven't shipped anything with it, never used it in anger, but I still like it.<p>I like to use Justin Woo's reference when looking for purescript library recomendations. <a href="https://purescript-resources.readthedocs.io/en/latest/" rel="nofollow">https://purescript-resources.readthedocs.io/en/latest/</a><p>I did use clojurescript in previous job (4 years ago). If you like lisp's it is nice. I did. I liked the libraries, and this was the first time I seen the "All the state of the app will be changed with atomic updates, there is only one state-var" pattern. I never did anything too complicated with it, and never used ffi.
On the <i>surface</i>, Elm has <i>fewer</i> features than the other the languages mentioned in the OP's question, that turns out to be a <i>really</i> good thing.<p>Having more language features just leads to more ways of doing the same thing which is more to "reason about" maintain and train new people to understand.<p>If you are building a small web app that needs to be Embedded in an existing/other web page, use Elm the resulting app will be <i>much</i> smaller.<p>If you are building a larger app that requires lots of JS "interop", use Elm and listen to the Elm-Town Podcast on Ports.<p>We @dwyl have been using Elm for the past 2 years on project ranging from small Progressive Web Apps (which load much faster than their React/Angular/ReasonML equivalents) to full e-commerce websites built by teams of 30+ people.<p>Elm <i>shines</i> in all the situations we have used it.
In some situations where we have JS server-side code we have used PureScript which some people consider more "full featured", but all that <i>really</i> means is: "I don't know how to do this in a simpler way, so I need the "advanced" language features..."<p>If your use-case is a (Web App Mobile-focussed or Desktop) and you want to "move fast" (without breaking things!), you will not find a better launch-pad than Elm.<p>Given the release of v0.19 last week, now is a _great_ time to dive in!
for my personal hobby project, i migrated it from elm to js-of-ocaml [<a href="https://ocsigen.org/js_of_ocaml/" rel="nofollow">https://ocsigen.org/js_of_ocaml/</a>] + lexifi's ocaml-vdom library [<a href="https://github.com/LexiFi/ocaml-vdom" rel="nofollow">https://github.com/LexiFi/ocaml-vdom</a>], and have been pretty happy with it. i did not go with bucklescript (i'm guessing by reasonml you mean reasonml + bucklescript, since that's the combination that has the community around it) because i wanted to make both a desktop app and a webapp from the same codebase, and js-of-ocaml fit that use case better.<p>if i primarily had to interop with javascript rather than with ocaml, i would give bucklescript (either with or without the reasonml frontend) a more serious look.