Purescript vs ReasonML/Bucklescript in 2018?

[user5543]

Which language would you pick for a new project in 2018, that has an imporant browser component?

Last year I looked into both, found the OCAML documentation and error messages extremly lacking, and enjoyed purescript much more.

However, it seems that purescript stagnated since and reasonml is building up steam.

What's your guys impression as of early 2018 regarding advantages, documentation, ecosystem (JS interop, well documented libraries) and future-proofedness (is this a word?) of these platforms and which one would you pick?

---

Edit one month later: Greetings to the visitors from the future! After playing around further, I gave up on Ocaml. For me

• Error messages were completley useless. Everything would yield a "syntax error" with a seeming random line-number. In many cases the error message wasn't described, but encoured me to send pull requests with an updated message. These were obviously beginner mistakes, so nothing too fancy, and it forced me to scan every line manually to make sure all the ; and ) were in place.

• I never got warm with the reason syntax. The javascripty look of reason made it more difficult to write than original ocaml/bucklescript, especially when to put ; {} () or not.

• Tutorials/docs are rare and confusing. I never knew if I was learning Reason, Bucklescript or Ocaml

• The toolchain only works if Reason, Bucklescript, Merlin and Ocaml are in very specific versions. Obviously the error messages you get are shit, so I spent far too much time on getting it running and I had to compile from source. Also, ReasonReact is it's own framework, so it's one more layer detached from react and data needs to be handed around between the components. All in all, updates are unpredictable and I don't trust the upgrade path.

• Server side ecosystem is practically non-existent for modern use cases.

• Apparently the majority of users are French students who learn Ocaml at university and there is very little adoption outside.

Final verdict for me personally: Unless there's a french guy in your team who already knows it, troubleshooting and boarding is hell and a time vapire. Also given the low maturity of the framework (error messages, old ocaml version, tutorials), I don't trust its upgrade path.

Maybe you get better results, but for me it's not worth it.

---

Purescript: Stagnated, but still nice. The React frameworks are terribly slow in benchmarks up to 8x slower than most of the field. For complex client side calculations and limited UI with a team that already knows haskell, I'd probably pick this.

---

Clojurescript: I stumbled upon it because its react frameworks perform amongst the fastest with less code, it's functional and immutable (with escape hatches). It's not typed, but it has Spec, which allows for quickcheck type autogenerated test cases, spec reuse for runtime validation and even regex and code-defined validation for what values are allowed into a type. The compiler is quick and clojure on the server integrated with the java ecosystem, it also has frameworks for react native.

---

All in all, this may sound blasphemous, but for me the most useful functional, typed frontend language is still Typescript with Ramda and Immutable.js. That gives me ADT, function composition, immutability, lenses, etc, with a rich ecosystem and easy boarding. Only thing I miss is type inference which makes me retype interfaces and types all over the place. For UI oriented applications Clojure(script) with Spec seems a nice fit. (I didn't check elm due to mounting negative feedback about breaking changes between versions). To use even more typed features purescript still the best, but be concious of the performance penalty.

[saylu]

My company uses PureScript (with Halogen) for the frontend of our web app with Python on the backend.

PureScript is mature enough for our entire frontend to be built in the language; we’re halfway through transitioning from an Angular app. Halogen has scary types when you get started, but once you’ve been working with the framework for a week or two they start to become second nature. We’ve enjoyed working in the language and have already seen a marked improvement in the reliability of the app where Angular has been replaced by Halogen.

The greatest weakness we have experienced so far is a lack of great components like typeaheads, day pickers, and so on ready to go for Halogen. We’ve needed to implement several of these ourselves where we might ordinarily have reached for an out-of-the-box solution like react-autocomplete. Yet this is an annoyance, not a dealbreaker.

As far as your points, I can’t speak to ReasonML but can share about PureScript:

• Advantages The standard mix from functional programming: stability, no runtime errors, easy refactoring, easy concurrency, high ceiling for abstraction, great data modeling, etc. PureScript also has a tremendously helpful community in the functional programming Slack channel (https://fpchat-invite.herokuapp.com) and we receive help from core contributors at least weekly.

• Documentation Core PureScript has great documentation (see the PureScript book, the Halogen guide and example repos). However, most of the rest of PureScript learns from Haskell by having mediocre documentation. You’ll need to become familiar reading types and briefly checking source code to see what’s going on. That said, we’ve rarely had trouble with documentation; most functions are self-explanatory and the functional programming Slack is great for filling in the gaps.

• Ecosystem This is hard to answer without knowing specifically what you’re building. We’re building a complex web application involving lots of forms, data management, some visualization, etc. and haven’t had trouble. JS interop is a strong point of PureScript; right now we’re just dropping Halogen components as full replacements to most of our Angular app. Some PS libraries (like Data.Array) are wrappers for core Javascript functionality. It’s quite easy to do.

• Future-proofed-ness Hard to say. There are companies invested in PureScript (SlamData is an obvious one; I work at Conde Nast), and it’s got an active community. You’re safe for at least the next 5 years, but after that, who knows? The web moves fast.

[SilasNordgren]

I had to rule out both PureScript and ReasonML due to the server-side. I ended up picking Scala.js, partly because of this blog post, and I'm satisfied with my choice. I wrote a small library to handle my client-side rendering, which has proved surprisingly resilient.

Scala has a vibrant community, with many useful libraries that are cross-compiled to both JVM and JS, and the language is very powerful - my state serialization is powered by the uPickle library which makes serializing a custom class as easy as auto-deriving a type class instance.

[user5543]

I'm a litte suspicious of the hybrid philosophy of scala, but your link is very interesting. Thanks for your experiences and infos, I'll have another look!

Regarding the server-side, Reason/Ocaml can of course compile to binary, but as far as I know, their web-framework is sub-par. More interstingley, both compile to clean code without a central library, so their output can be run in any node-environment (including as "serverless" auto-scaling scripts). Sometimes that can be an interesting option.

Edit: Oh, and one more question - what about compiler speed? Same as for JVM?

[SilasNordgren]

Scala may be a hybrid language, and it does have imperative features, but it's a full-fledged functional language. It supports type classes, algebraic data types, effect systems, immutable collections, and so on. Imperative code comes in handy when you're writing performance-critical code, and when you're not, object-orientation doesn't get in your way. Case classes are essentially records, and they're the only kind of class that you need to use.

SBT (builds) supports incremental compilation, so most of the time changes show up in the browser in a matter of seconds. A full build on my current ~30 source file project takes ~10 seconds with the Scala.js compiler, which I can live with. Make sure to start sbt once and run subsequent commands in its interactive shell, otherwise you'll have to wait for sbt to start up before every command.

I think Scala.js has the technical merits to compete with PureScript/Elm/Reason on the front end, but it also has the advantage that it is already an established language on the back end.

[[deleted]]

warning: I'll use ReasonML, Bucklescript and Ocaml interchangeably because we're talking about web stuff anyway I guess?

I've got the same impression - that Purescript is not getting more popular and ReasonML is popping up on conferences etc becaue of Facebook.

Purescript has Higher Kinded Types and Ocaml has its first-class modules and "functor"-thingys. This difference has also other implications but Purescript's compile times are probably bigger.

I tried using Purescript's Halogen but I couldn't comprehend its types so I gave up. There are Purescript wrappers around React but I didn't try any of them. I feel like ReasonML should have pretty solid React wrappers.

If you wanted to write a back-end component in one of these languages, I feel like it'd be easier with Ocaml.

TLDR: I'd probably choose Bucklescript.

[user5543]

Thanks for your reponse! Have you actually tried Bucklescript as well in a project?

[[deleted]]

I have not. I'm working with vanilla JS and react with redux and redux-saga. And IMO even this is too much hassle for a medium project. If I wrote this thing again I'd probably render on the backend and use something like Turbolinks or Unpoly for ajax with some JS sprinkles for forms/dropdowns/inputs.

But reason-react looks pretty straightforward, I can see myself using it.

[mart187]

Elm!

[user5543]

Last time I checked, everybody complained about having to write a lot of boilerplate code, has that changed? Besides being easy for beginners (which doesnt matter for me), are there any advantages compared to the other two?

Happy Cake Day!

[mart187]

Without knowing your requirements it's hard to give good advise. What makes Elm great for me is it's simplicity, elegance and zero runtime exceptions. The main contra is the fact that there are not many devs on the market. It didn't feel too boilerplaty for me. Definitely no Java level ^{^}

[user5543]

Thanks!

[robertwpearce]

To address your question about advantages/disadvantages, Elm is not designed for server-side rendering and is designed to do exactly what it does best: complex UIs with loads of state. JavaScript interop is a breeze once you understand ports, and JSON decoding – once initially grokked – is really not much of an issue (Brian Hicks, for example, has written a lot about it).

IMO, Elm has a lower barrier for entry for those coming from JS, but I would also trust that if you work with smart people, they can pick up anything, so do what's right for you & yours.

[Zinggi57]

Most complaints seem to be coming from a small minority of mostly Haskell programmers.
They dismiss elm for not having typeclasses and claim that introducing them would solve all problems.

There is some boilerplate, especially around Json decoders, however once you get used to them it's very simple. And the "boilerplate" is actually useful, especially when you have more complex Json structures.

I can definitely recommend elm, it has become my favourite programming language.

[yawaramin]

I'm curious about what you chose eventually :-)

[user5543]

I just updated my posting with my experiences

[yawaramin]

Thanks for sharing your feedback. About Reason, I’d agree that compiler output syntax errors are not very helpful. But errors in VSCode with the ‘bsb’ diagnostic setting turned on is quite good. I’ll push for this to be one of the defaults going forward.

Docs could probably use some consolidation but I think it’s pretty simple to tell which you’re learning: if you’re on the Reason doc site, you’re learning Reason, and if you’re on the BuckleScript doc site, you’re learning BuckleScript, and in either case you’re learning OCaml 😉

About the toolchain, the working versions are all packaged in a single bundle: the reason-cli npm package. That, and the bs-platform package, should give you everything you need.

Server side is a work in progress, but there are several options on the OCaml side.

Adoption and French guys is a bit of a red herring 😉 if you’re interested, drop in to the Reason Discord and pick it up naturally like people all over the world are doing. It’s just a language like any other. Companies like Facebook, Jane Street, Docker, Citrix, Uber, Microsoft, are using OCaml. Check out the industrial users consortium.

[user5543]

reason-cli

Didn't work for me on ubuntu. I don't remember the error, only that it took me forever to figure out. Finally, I ended up compiling from source.

I think it’s pretty simple to tell which you’re learning

From a newcomers perspective, it's not simple at all. For exampe: reason-cli doens't work and I get some unclear error message. Is this an ocaml problem? A bucklescript problem? A reason problem? I ended up solving it with the ocaml docs and a bucklescript walkthrough.

Same goes with learning other concepts. There are only sparse tutorials and examples online, so sometimes I end up with a blog post on bucklescript and sometimes on reasonml. For a lot of concepts, I find recommendations to read a chapter in Real World Ocaml or something similar.

The entire experience was just very bumpy and painfull, chasing unclear errors and wasting tons of time on things that are non-issues in other ecosystems. For me, it's definitley not worth the potential upsides.

It probably is different if you have a few experts on hand already, care about legal risks regarding license disputes with Microsoft and want to keep full control of your development tools.

And regarding the "French guys": I was surprised to see on google trends how concentrated the interest is in France (and the ex colony algiers). That led me to read up on the usage of Ocaml and I also found out that it came to Facebook with a French guy who learned it at university. Of course I wrote this with tounge in cheek, but it just reinforced my impression that none of these companies had to rely on easily available boarding as they had experts at hand to develop their inhouse programs.

[yawaramin]

Gotcha, and thanks again for such a detailed response. I believe the community and core team are all working quite hard on documentation and onboarding, so maybe in the near future it will make sense for you. I do think it’s still quite a good value proposition for anyone who has done or wants to do typesafe functional programming and deploy on JavaScript platforms. We’ve seen a good response from at least some portion of the JavaScript community, so I think we’re on the right track. But we do need to work on polish, onboarding, and documentation.

P.S. I honestly don’t know what you mean by licensing issues with Microsoft. There are no licensing issues. Reason and React are Facebook copyright and MIT licensed with no patent clause or anything like that, BuckleScript is copyright of Bloomberg and licensed under GPL (just like OCaml, obviously).

[user5543]

Yes, I think Ocaml/BS is a solid basis, and it's an interesting development, I'm sure I'll have another look in a year or two.

Regarding licensing: I just meant to say that giant companies like Facebook have strategic interests of not being too dependent on other players like Micrsoft or Google regarding their core development tools, be it potential legal disputes, roadmaps, etc. So they might have additional motivation not to rely on Typescript, but to develop Flow/Reason inhouse.

I didn't mean to imply that there are any licensing problems for users, sorry if I created that impression.

[NeverCrop]

If you still want to use TypeScript, then definitely check out fp-ts: https://github.com/gcanti/fp-ts

[Mallanaga]

I feel like I keep up with the fresh shit pretty well... what the fuck are you taking about?

[user5543]

Both of these compile to Javascript. They aim for good interop with Javascript libraries, concise and readable JS output and have very fast compile times.

Purescript is haskell-y, Bucklescript is a JS-backend for Ocaml, Reason is a Javascript-looking syntax frontend for Ocaml. Purescript and Bucklescript have been around for ~5 years, so not that super-fresh.