ReasonML 与 TypeScript

ReasonML vs TypeScript

提问by Ben Nelson

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

ReasonML ( https://reasonml.github.io/) 和 TypeScript ( https://www.typescriptlang.org/)之间的权衡是什么？

回答by Thomas

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

现在有很多语言以 JavaScript 为目标。选择其中之一取决于您的需求和您熟悉的习语。

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

JavaScript 有一个动态类型系统。一些开发人员更喜欢静态的。

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

• TypeScript 或 Haxe 使用一种新语言解决了这个问题，该语言是静态类型的并且只能转译为 JavaScript。

• Flow 是一个 JavaScript 预处理器，它针对相同的问题，但无需学习新语言。如果您只需要一个类型系统，我更喜欢这种方法。

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, ...).

一些 JS 开发人员想要更多并使用更多的函数式编程习语（代数数据结构、不变性、模式匹配等）。许多编程语言都可以做到（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.

• ReasonML 是 OCaml 的一种语法，可以通过 BuckleScript 编译为本机或 JavaScript。你可以用 Reason 实现的所有功能也可以用 OCaml 来实现，除了 ReasonML 语法接受 JSX。ReasonML 可以轻松定位 node.js 应用程序、react.js 应用程序或原生应用程序。

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

如果您来自 Java 或 C# 世界，那么 TypeScript 很容易学习。

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

如果您从未使用 ML 语言（OCaml 或 F#）进行开发，则 ReasonML 更难学习

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

• 如果你只需要一个静态类型系统，你应该考虑 TypeScript

• 如果你需要一个类型系统来做 react.js 或 react-native 应用程序，你应该考虑 ReasonML，因为 ReasonReact 是对 react.js 的巨大改进

• 如果你需要一种编译成 js 的函数式编程语言，你应该考虑 ReasonML

回答by glennsl

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.

有许多权衡，其中许多源于 ReasonML 在技术上只是 OCaml，因此继承了 OCaml 25 年作为本机编译语言的历史的大部分设计决策，很少考虑网络上这个奇怪的 JavaScript 利基。

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.

但实际上，我认为最大的权衡是在 ReasonML 健全且灵活的类型系统与 TypeScript 轻松“潜入”现有 JavaScript 代码库的综合静态检查的能力之间。

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 的类型系统被明确设计为不健全的，因此虽然大多数时候它会给你帮助，但它不能给你很多保证。你真的不能完全相信类型系统会支持你，这是拥有适当静态类型系统的最大优势之一。

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.

TypeScript 还受到其避免运行时类型信息的决定的限制，这对于模式匹配等功能以及在 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 :)

另一方面，ReasonML 要求明确定义其自身与现有 JavaScript 代码之间的边界。可以在某种程度上推断类型，但它们仍然必须在编译时确定。这使得 JavaScript 互操作更加费力，尤其是当边界随着现有 JavaScript 代码库的转换而逐渐移动时。如何在 JavaScript 中输入一些奇怪的东西也并不总是很明显，但它通常是可能的，并且希望只是暂时的，直到所有东西都被转换为 ReasonML :)

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.

显然我有偏见，但我希望这不会被认为是选择了一个明显的赢家，至少因为真的没有。这是一个重大的权衡，至少只要世界不完美。

回答by gladimdim

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.

在大型应用程序中，您将需要许多功能，这些功能在 ReasonML 中默认提供：严格类型、编码/解码 JSON 时的运行时验证、快速编译时间、不可变数据。

In TypeScript you will have to add:

在 TypeScript 中，您必须添加：

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.

1. ImmutableJS + 它的类型。
2. 运行时验证器，如json-schema+ 它的类型。然后你将不得不在 TypeScript 中编写类型，并在 json-schema 中定义一个模式。它们很快就会变得不同步。
3. 一些疯狂的技巧来区分变量是否属于特定类型（例如在 TS 的官方文档中：https: //www.typescriptlang.org/docs/handbook/advanced-types.html，段落“用户定义的类型保护”） . 这个检查是使用副作用完成的，比如 a.swim !== undefined。6 个月后，这个“if”语句将包含越来越多的检查。
4. 如果您使用的包具有官方和维护的类型定义，那么您很幸运。或者你最终会得到自定义类型。
5. 如果您在 JS + TS 中开发混合应用程序，那么 TS Compiler 无法创建捆绑的最终 d.ts 文件，您可以将其导入项目的其他部分。您必须编写单独的 d.ts 文件，这些文件由dts-bundle 之类的工具捆绑。如果您在 TS 中拥有所有内容，则此问题不适用。
6. 大型应用程序需要大量时间才能由 TypeScript 编译。

With ReasonML:

使用 ReasonML：

1. Immutable data is in the language.
2. Runtime validators are present (bs-jsonhas 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.

1. 不可变数据在语言中。
2. 存在运行时验证器（默认情况下bs-json具有它们）
3. 模式匹配使您免于这些疯狂的检查。
4. 如果您要使用的 npm 包具有 BuckleScript 绑定，则您很幸运。
5. 不适用。
6. ReasonML 编译速度非常快。

回答by wires

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

ML 系列语言基于称为 System-F 的类型理论，例如 Purescript 和 Haskell 也使用该理论。

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

Typescript 缺乏如此完善的基础，而是使用具有许多特殊位的新实验类型系统（我什至不确定它是否“正式化”）。

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.

因此，从表面上看，TS 的方法可能看起来“实用”，但它引入了更多必要的复杂性。系统 F 有少量规则组成系统，它非常通用，但更容易推理该 TS 的“理论”。少即是多。

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

此外，学习 System-F 的努力是永恒的，并且可以转换为其他更强大的语言，例如 Purescript。

回答by basarat

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

• ReasonML 是一种不同于 JavaScript 的语言，它可以编译成 JavaScript
• TypeScript 是 JavaScript 的严格超集，可编译为 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 languagethat compiles down to JavaScript then ReasonML is one of many options. The some languagein ReasonML's case is OCAML.

• 如果您想编写类型安全的JavaScript，则可以选择 TypeScript。

• 如果您想编写类型安全的某种编译为 JavaScript 的语言，那么 ReasonML 是众多选择之一。ReasonML 案例中的某种语言是 OCAML。

More

更多的

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

我的偏见：https: //medium.com/@basarat/typescript-won-a4e0dfde4b08

回答by Abdul Kader Jeelani

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.

Reason ML 带有功能第一学校，如果您有这种心态，那就是 Go 的方式。而 typescript 可以做 fp 并且也有很好的社区支持。几乎所有流行的库都有打字稿类型。我更喜欢使用 fpts ( https://github.com/gcanti/fp-ts/blob/master/README.md)。它提供了打字稿中 fp 的所有优点，包括运行时检查。尽管类型构造函数在 ts 中是一个很大的缺失。如果您可以忍受它，请选择 ts。