
Ask HN: ReasonML, ClojureScript, Purescript or Elm? - kuwze
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&#x2F;cons you used to make your decision.
======
mjaniczek
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 :)

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.

------
yogthos
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.

This workshop runs through all the basics of building a small app from start
to finish [https://github.com/ClojureTO/JS-
Workshop](https://github.com/ClojureTO/JS-Workshop)

------
aarpmcgee
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)

------
z5h
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.

------
Nelkins
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.

[0] [http://fable.io/](http://fable.io/)

------
a-saleh
For side-projects I like to play around with PureScript.

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/](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.

------
nelsonic
On the _surface_ , Elm has _fewer_ features than the other the languages
mentioned in the OP's question, that turns out to be a _really_ good thing.

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!

~~~
jkachmar
> 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..."

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/](https://noredink.github.io/json-
to-elm/)

[1] [https://github.com/justinwoo/purescript-simple-
json](https://github.com/justinwoo/purescript-simple-json)

[2] [https://www.slideshare.net/JosephKachmar/lc2018-input-
valida...](https://www.slideshare.net/JosephKachmar/lc2018-input-validation-
in-purescript)

------
zem
for my personal hobby project, i migrated it from elm to js-of-ocaml
[[https://ocsigen.org/js_of_ocaml/](https://ocsigen.org/js_of_ocaml/)] +
lexifi's ocaml-vdom library [[https://github.com/LexiFi/ocaml-
vdom](https://github.com/LexiFi/ocaml-vdom)], 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.

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.

------
knewter
Elm

