How do you feel about Ramda, etc (functional JS) and how to market ReasonML to functional-JS lovers?


I have a coworker who loves Ramda, he usually writes code like:

export const truncateAtWith = curry((length, callback) =>
    // split splitable text by checking length
    propSatisfies(gt(__, length), 'length'),
    // callback so render ui can be dealt by caller
    pipe(trim, splitAt(length), head, callback),

Personally, this looks horrible to me because I like native JS syntax just fine, and I don’t want to go through the mental gymnastics of reading this code, as well as learning about 100 Ramda functions. Although I can’t quite get why he likes this, I know there’s a lot of people who do like ramda (and lodash, etc), so there must be a reason for it (pun intended). As a Reason person who has used these libraries, what would you tell a coworker to help them love Reason?

Note: I know Reason has automatic currying, so I bet that’s the first plus :slight_smile:

Note 2: I believe my co-worker believes the above code is more efficient because it’s “functional”. I don’t think that’s true because I know there’s a lot of optimization of native JS code as long as I write a pure function that does the same as this, and loading and parsing ramda library adds overhead. Can anyone smarter than me verify my hunch?

Note 3: I know there’s Rationale, which may provide some nice functions for Ramda-lovers in Reason.


I think selling ReasonML to FP lovers is to first talk about its strong points.

Type Inference and strong type checking

Coming from JS land there is Flow and TypeScript as options for static analysis. However, it adds an additional layer to development that can’t really be considered a seamless addition. The developer still has to do much of the work of declaring types within functions for example instead of them being known already. Additionally, this extra layer can feel like you are adding type safety but only if you are strict about it. No any or other cutting corners when it comes to types. This strictness is built into reason development from the beginning so you are from the start held to a higher standard.

Most Approachable Syntax/Ecosystem

People who say syntax doesn’t matter is a lier :smile: There are all kinds of flavors of fp. If you want more expressivness, then try PureScript. If you want simplicty and you are doing front-end then try out Elm. But in the process you are learning a new syntax and ecosystem. Reason shines in the fact that it looks like plain JavaScript and can go even further because it has a nice foreign function interface. Additionally, many common JS libraries have been wrapped using FFI and for those JS people they will feel right at home using APIs they are most familiar with. As a by-product this makes you more productive.


I think in comparison to other fp languages/frameworks out there it puts you in the best position to be productive. I am mostly a FE developer so when I talk about FE frameworks I am talking about Halogen in PureScript and TEA in Elm. Halogen is very high level for me. TEA is too constricting because I can’t create components natively. Reason has bindings for React which allows me to be quite productive because it’s a paradigm I am already familiar with.

Pattern Matching

Once someone learns about pattern matching they will wonder why it was never added to the language they use most often. I say this to myself every time I have to go back to using JS.

That’s all I can think of at the moment. If more ideas come to me I will write them down. I think you are on the right path and I think speaking to Reason’s strengths is a good place to start. We have to understand that Flow, TypeScript, Ramda, etc is all a response for what JS is missing. When you then use a language that has those features from the start, appreciate how far ahead of the game it puts you.


I like the things you mentioned, I think it’s a good way to approach the “marketing” of Reason (I don’t like marketing usually, but the reality is that everything is being marketed one way or another).

Also while PureScript and Elm are cool technologies, the reality is 99% of people don’t have time to learn cool new technologies, they are just using Javascript. Ramda gives you (presumably) some of the benefits of FP in the ecosystem everyone already knows, but it’s really not great either.

If Reason can take even 10% of the market share of Javascript, that would already huge.


Maybe it is better to also target users of other more advanced FP libraries like sanctuary.js