ReasonML vs TypeScript

问题:

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

回答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

回答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.

回答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.

回答4:

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

回答5:

(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.

回答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.