62

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

4

6 回答 6

69

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

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

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

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

一些 JS 开发人员想要更多并使用更多的函数式编程习惯（代数数据结构、不变性、模式匹配……）。很多编程语言都可以做到（OCaml、Haskell、ReasonML、F#、Scala，...）。

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

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

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

我的建议：

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

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

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

于 2017-10-25T14:38:35.040 回答
48

有许多取舍，其中许多源于 ReasonML 在技术上只是 OCaml，因此继承了 OCaml 25 年的原生编译语言历史中的大部分设计决策，而很少考虑网络上这个奇怪的 JavaScript 利基市场。

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

TypeScript 的类型系统被明确设计为不健全，因此虽然它在大多数情况下可以帮助您，但它无法为您提供很多保证。你真的不能完全相信类型系统会支持你，这是拥有适当静态类型系统的最大优势之一。

TypeScript 还受到其避免运行时类型信息的决定的限制，这对于模式匹配等功能以及在 ReasonML 中处理类型化数据的主要好处是必需的。

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

显然我有偏见，但我希望这不会让人觉得至少是在挑选一个明显的赢家，因为真的没有。这是一个重大的权衡，至少只要世界不完美。

于 2017-09-14T15:21:56.440 回答
21

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

在 TypeScript 中，您必须添加：

  1. ImmutableJS + 它的类型。
  2. 运行时验证器，如json-schema + 它的类型。然后你必须在 TypeScript 中编写类型，并在 json-schemas 中定义一个模式。它们很快就会变得不同步。
  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 编译大型应用程序需要大量时间。

使用 ReasonML：

  1. 不可变数据在语言中。
  2. 存在运行时验证器（bs-json默认有它们）
  3. 模式匹配使您免于这些疯狂的检查。
  4. 如果你想使用的 npm 包有 BuckleScript 绑定，你是幸运的。
  5. 不适用。
  6. ReasonML 编译非常快。
于 2017-12-22T16:06:14.577 回答
19

（只是一个注释）

把所有实际的方面放在一边；

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

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

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

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

于 2018-08-19T12:43:52.107 回答
9

非常不同。

  • ReasonML 是一种与 JavaScript 不同的语言，它可以编译成 JavaScript
  • TypeScript 是 JavaScript 的严格超集，可编译为 JavaScript

如果你想编写类型安全的代码，两者都是很好的选择。

  • 如果你想编写类型安全的JavaScript，那么 TypeScript 是不二之选。

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

更多的

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

于 2017-09-11T04:22:18.580 回答
2

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

于 2018-10-30T12:08:15.133 回答