ReasonML vs TypeScript

Question

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

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

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.