ReasonML vs TypeScript

Question

What are the tradeoffs between ReasonML (https://reasonml.github.io/) and TypeScript (https://www.typescriptlang.org/)?

Beefsteak

I think this is like comparing apples and pears. I would take some time to research these languages and many of the others yourself. You won't get a good understanding of the key differences by just looking at the tradeoffs. – Broadway

apparently ReasonML is the future. I have been to several conferences and everyone talks about it and talk about how cool it is. I def want to get into it. There people developing apps with react and reason (ReasonReact) and they are super fast. – Tetrapody

If you use ReasonML you get actual guaranteed Types and can start using things like this: imandra.ai. If you just want JavaScript that looks more like Java then go with TypeScript. – Howard

Answer 1

There are lot of languages nowadays that target JavaScript. Choosing one of them depends on your needs and the idioms you're comfortable with.

JavaScript has a dynamic type system. Some developers prefer a static one.

• TypeScript or Haxe solves this with a new language that is statically typed and only transpiles to JavaScript.

• Flow is a JavaScript preprocessor that targets the same issue but without the need to learn a new language. I prefer this approach if you only need a type system.

Some JS developers want more and use more functional programming idioms (algebraic data structures, immutability, pattern matching, ...). A lot of programming languages can do it (OCaml, Haskell, ReasonML, F#, Scala, ...).

• ReasonML is a syntax for OCaml that can compile to either native or JavaScript through BuckleScript. All you can achieve with Reason can also be achieved with OCaml, except that the ReasonML syntax accepts JSX. ReasonML can easily target node.js app, react.js app or native app.

TypeScript is easy to learn if you come from the Java or C# world.

ReasonML is harder to learn if you never developed with an ML language (OCaml or F#)

My advice:

• If you just need a static type system, you should consider TypeScript

• If you need a type system to do a react.js or react-native app, you should consider ReasonML because ReasonReact is a huge improvement over react.js

• If you need a functional programming language that compiles to js, you should consider ReasonML

Shamblin

by dynamically typed and statically typed, do you mean strongly typed and loosely typed? – Skipper

Not really. Dynamically typed means that type is evaluate at runtime, while statically means that type is evaluate at compilation. strongly typed and loosely (or weakly) typed is more controversial. I like this definition youtu.be/UXBoiqRJ6DQ?t=5m6s – Shamblin

@Shamblin flow and typescript are virtually identical, why do you consider typescript 'a new language' – Orb

@TomCumming both are aimed at typing JS but Typescript is a full language - even if it's a superset of js - while flow is just a javascript preprocessor. TS code must be compiled to JS with Typescript compilator (written in Typescript) to run. JS with Flow's annotation should be preprocessed by flow (written in OCaml) but it may run (or transpiled) by babel without be preprocessed by flow. A good reading about inference engines : codeburst.io/… – Shamblin

@Shamblin could you share if you are currently working on a project that's using ReasonML in production? – Bovid

@Bovid yes I use some reasonML in my project but not open source it. I made a training with my students if you would try it github.com/miage-lille/age-of-reason – Shamblin

I think you need to expand upon your justification for Flow over TS: "but without the need to learn a new language" Example flow: function foo(x: ?number): string { It's basically the same thing – Harday

@DominicWatson in both you need to learn about types and how to use them. That's their purpose. Since all javascript code is suppose to be correct typescript code, it's not mandatory to learn TS lang to do typed javascript with TS ... but TS comes with specific programming features like decorators or ambient module declaration. Neverless with the maturity of projects like ReasonML but also ELM or Nim and the growing of their communities, interest to learn both (flow & ts) are decreasing. – Shamblin

yeah how do libs in node_modules interop with Reason code? – Stereopticon

@rakim You can either bind the lib directly in your reasonML code with Buckelscript bucklescript.github.io/docs/en/import-export If you need re-use / complete coverage of a node module, you can create a bs module which is actually a node module bind with your bsconfig.json : search for libs named bs-* on npm for exemples ;) – Shamblin

> If you need a type system to do a react.js or react-native app, you should consider ReasonML because ReasonReact is a huge improvement over react.js ---- Can you provide evidence of this statement? In what ways is ReasonReact "a huge improvement over react.js"? And are you comparing with React written in javascript or are you comparing to React written in TypeScript? – Adjustment

Answer 2

There are many trade-offs, many of them stemming from ReasonML technically just being OCaml and therefore inheriting most of the design decisions from OCaml's 25-year old history of being a natively compiled language with little regard for this strange JavaScript niche on the web.

But as it is I think the biggest trade-off is between ReasonML's sound and flexible type system, and TypeScript's ability to easily "sneak" comprehensive static checks into an existing JavaScript code base.

TypeScript's type system is explicitly designed to not be sound, and so while it will give you a hand most of the time, it won't be able to give you many guarantees. You really can't fully trust the type system to have your back, which is one the biggest advantages of having a proper static type system.

TypeScript is also limited by its decision of avoiding runtime type information, which is necessary for features such as pattern matching and a major benefit of working with typed data in ReasonML.

ReasonML on the other hand requires that the boundary between itself and existing JavaScript code is explicitly defined. Types can to some extent be inferred, but they must still be determined at compile-time. This makes JavaScript interoperation more laborious, especially if the boundary gradually moves as an existing JavaScript code base is converted. It's also not always obvious how to type some of the weird stuff that goes on In JavaScript, but it's usually possible, and hopefully just temporary until everything has been converted to ReasonML anyway :)

Obviously I'm biased, but I hope this doesn't come across as picking a clear winner at least because there really isn't. This is a major trade-off, at least as long as the world's not perfect.

Oracular

could you share if you are currently working on a project that's using ReasonML in production? – Bovid

I have a few open source projects currently in production, so to speak: redex and rebench. I'm currently working with F# and Fable, though that project is still far from production-ready. – Oracular

@Oracular It'd be interesting if you could briefly comment on your experience with F# now 5 years later? Also, your experience with Reason / ReScript? – Retain

Hi @Magne. I ditched F# shortly after this due to tooling issues and other opportunities. I don't think it's improved much since then, rather the opposite from what I've heard due to less support from MS. I've since worked a bit with native Reason, and for the past few years with ReScript. The split between Reason and ReScript has sent Reason in the direction of better tooling and ReSscript in the direction of better ergonomics and smoother interop. Most everything else, such as the type system, is essentially identical. – Oracular

Also, to answer your question from several years ago @bernatfortet, I'm currently working on a project that has 50k lines of ReScript in production. And I used to work on Onivim2, which was an open source, early access project using native ReasonML. You can check that out here: github.com/onivim/oni2 – Oracular

Answer 3

In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data.

In TypeScript you will have to add:

1. ImmutableJS + its typings.
2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon.
3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types.html, Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks.
4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings.
5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable.
6. Large apps take a lot of time to be compiled by TypeScript.

With ReasonML:

1. Immutable data is in the language.
2. Runtime validators are present (bs-json has them by default)
3. Pattern matching saves you from these crazy checks.
4. You are lucky if npm package you want to use has BuckleScript bindings.
5. N/A.
6. ReasonML compilation is very fast.

Cancan

If you want to achieve immutability in Typescript ImmutableJS is not necessary. Just use 'readonly' property modifier and types like ReadonlyArray, ReadonlyMap, Readonly etc. All these things are included in language and its standard library. – Stow

There is a big difference between having them in the language and having them as default, though. Reason is Immutable by default. – Osculate

You presume that the OP will want to use immutable data. IMHO when using typescript it's a better choice to adhere to OOP-so when you need state management something like mobx or mobx-state-tree makes much more sense. But you can easily get around it just by using the native react.js apis. Immutability is a win when you have multithreading. On the wed you don't so you may as well use OOP for your app's data. Also do you have any benchmarks confirming that TS is slow for large apps? I haven't had any slowness so far for any of my production apps. – Scotch

@Scotch If the OP considering using ReasonML then there's a good chance that immutability is one of the things they're after. Most people will probably have heard of Reason through React, and given how often React docs talk about the powers of immutability e.g. Redux, plus Facebook having developed Immutable.js too, it seems reasonable that the OP is interested by immutability. – Howard

@Scotch TypeScript seems to be aimed more at the C++/Java devs that are using Angular - most of these devs would be less interested in immutability but I also suspect that they wouldn't really be interested in switching the ReasonML either. – Howard

For me, the sixth point is should be on top. Having worked on Scala projects in the past, you quickly appreciate the fast feedback loop of the alternatives. ReasonML is lightning fast compared to its competitors. – Summertree

The sixth point is no longer true for TypeScript: Incremental compilation arrived some time ago, and building big apps means just recompiling the code that changed. Also, point 2 is also wrong today with respect to TypeScript: You can generate JSON schemas from TypeScript code. I do that in several projects. ts-json-schema-generator is one option, for instance. No synchronization problems possible. Point 4 is increasingly wrong as well: More and more packages are WRITTEN in TypeScirpt, but most popular ones have declarations. – Keneth

Answer 4

(just a note)

Putting all practical aspects aside;

The ML family of languages are based on a type theory called System-F, which is also used by Purescript and Haskell, for instance.

Typescript lacks such a well established foundation and instead uses a new experimental type system with many special bits (I am not even sure if it's "formalised").

So on the surface, TS's approach might seem "practical", but it introduces more complexity that necessary. System F has a small number of rules that make up the system and it is very general, yet easier to reason about that TS's "theory". Less is more.

Also, effort put into learning System-F is rather timeless and translates to other, more powerful languages, such as Purescript.

Forebrain

Answer 5

The are very different.

• ReasonML is a distinct language from JavaScript that compiles down to JavaScript
• TypeScript is a strict superset of JavaScript that compiles down to JavaScript

If you want to write typesafe code both are excellent choices.

• If you want to write typesafe JavaScript, then TypeScript is the option.

• If you want to write typesafe some language that compiles down to JavaScript then ReasonML is one of many options. The some language in ReasonML's case is OCAML.

More

My biased opinion : https://medium.com/@basarat/typescript-won-a4e0dfde4b08

Toney

Your answer and opinion fails to mention that reason is more like F#, Immutable with union types. Reason is nothing like typescript and was planned to be the engine behind React. A lot of Facebook front end code is currently re written in ReasonML – Irrigate

Answer 6

Reason ML comes with functional first School, If you are in that mind set that's the way to Go. Whereas typescript can do fp and also has good community support. Almost all popular libraries has typescript typings. I prefer using fpts (https://github.com/gcanti/fp-ts/blob/master/README.md). It provides all the goodness of fp in typescript that includes runtime check as well. Although type constructor is a big miss in ts. Choose ts if you are okay to live with it.

Molecular