Ask HN: ReasonML, ClojureScript, Purescript or Elm?
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.
10 comments
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
This workshop runs through all the basics of building a small app from start to finish https://github.com/ClojureTO/JS-Workshop
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/
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.
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.
Elm
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.
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.
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.
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!
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!
> 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/
[1] https://github.com/justinwoo/purescript-simple-json
[2] https://www.slideshare.net/JosephKachmar/lc2018-input-valida...
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...
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/
[0] http://fable.io/
for my personal hobby project, i migrated it from elm to js-of-ocaml [https://ocsigen.org/js_of_ocaml/] + lexifi's ocaml-vdom library [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.
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.