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.
Purescript is like Elm, just with less hand-holding and more advanced everything. Might suit you if you like Haskell?
No experience with ReasonML.
Edit: speaking more generally, I'd take anything with algebraic datatypes. Thankfully most modern languages do have them nowadays.
This workshop runs through all the basics of building a small app from start to finish https://github.com/ClojureTO/JS-Workshop
[0] http://fable.io/
Mostly because I really like things like simple-json, where it can parse a json string based just on the type you are expecting.
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.
If you need even more escape hatches, the FFI is quite un-assuming.
On the other hand, I haven't shipped anything with it, never used it in anger, but I still like it.
I like to use Justin Woo's reference when looking for purescript library recomendations. https://purescript-resources.readthedocs.io/en/latest/
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.
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.
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 much smaller.
If you are building a larger app that requires lots of JS "interop", use Elm and listen to the Elm-Town Podcast on Ports.
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.
Elm shines 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 really means is: "I don't know how to do this in a simpler way, so I need the "advanced" language features..."
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.
Given the release of v0.19 last week, now is a _great_ time to dive in!
I disagree with most of your comment, but I want to respond to this one section in particular.
I enjoy using PureScript in place of languages without the "advanced" features because it lets me express things that are otherwise _not expressible_. That doesn't make the language more complex, or less "simple" if you prefer, but it _does_ arm its users with the tools necessary to create more powerful abstractions, should they need them.
Will some of these abstractions end up introducing more complexity? Perhaps. However, one can write simplified code in a language that admits more powerful abstractions while the reverse _is not true_.
When someone decides that they don't want to use higher kinded types or typeclasses in PureScript, they can _choose_ not to use them.
When someone runs into a problem that would be made easier with higher kinded types or typeclasses in Elm, they _cannot choose at all_.
Nowhere is this point driven home more clearly than when deriving JSON encoders and decoders. The last time I checked, users were advised to codegen complex JSON codecs using a web app [0].
Compare this with PureScript, where the language's features can be used to automatically derive JSON codecs from a simple type alias that looks nearly identical to the JSON itself [1].
And these are just two features that are directly comparable. A few months back, I gave a talk on how these "advanced features" can be used to construct functions that can be combined to create complex pieces of input validation logic. These functions can be safely mixed, matched, and extended with strong guarantees that any and all failures will be propagated back to the caller in the form of typed error messages [2].
Anyway, I'm sorry if this rant was just the result of me having read farther into that one part of your comment than you intended. I don't think there's anything wrong with people using Elm, and I'm glad that there are more avenues into strongly typed, functional programming than just Haskell and PureScript.
I just see this line of "Elm is simple" brought out in response to these other languages, and feel that it entirely misses the point of why those languages added the features in the first place.
[0] https://noredink.github.io/json-to-elm/
[1] https://github.com/justinwoo/purescript-simple-json
[2] https://www.slideshare.net/JosephKachmar/lc2018-input-valida...
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.