ReasonML与TypeScript

时间:2017-09-11 01:59:05

标签: typescript reason bucklescript

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

6 个答案:

答案 0 :(得分:47)

现在有很多针对JavaScript的语言。 选择其中一个取决于您的需求以及您感到满意的idioms

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

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

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

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

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

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

如果您从未使用ML语言(OCaml或F#)开发,那么ReasonML更难学习

我的建议:

  • 如果您只需要静态类型系统,则应考虑使用TypeScript

  • 如果您需要类型系统来执行react.js或react-native应用程序,您应该考虑ReasonML,因为ReasonReact是对react.js的巨大改进

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

答案 1 :(得分:33)

有许多权衡取舍,其中许多源于ReasonML技术上只是OCaml,因此继承了OCaml 25年历史上的大多数设计决策,这些历史是一种本地编译的语言,很少关注这个奇怪的JavaScript利基网络。

但是我认为最大的权衡是在ReasonML的声音和灵活类型系统之间,以及TypeScript能够轻松地将全面的静态检查“偷偷摸摸”到现有的JavaScript代码库中。

TypeScript的类型系统明确地设计为不合理,因此虽然它会在大多数时间为您提供帮助,但它无法为您提供许多保证。你真的不能完全信任类型系统让你的背部,这是拥有一个适当的静态类型系统的最大优势之一。

TypeScript也受限于避免运行时类型信息的决定,这对于模式匹配等功能是必需的,并且是在ReasonML中使用类型化数据的主要好处。

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

显然我有偏见,但我希望这并不是因为选择一个明显的赢家,至少因为确实没有。这是一个重要的权衡,至少只要世界并不完美。

答案 2 :(得分:16)

在大型应用程序中,您需要很多功能,这些功能在ReasonML中默认提供:严格类型,运行时验证(如果您编码/解码JSON),快速编译时间,不可变数据。

在TypeScript中,您必须添加:

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

    1. 不可变数据使用该语言。
    2. 存在运行时验证程序(默认情况下bs-json有)
    3. 模式匹配可以帮助您避免这些疯狂的检查。
    4. 如果您想要使用的npm包具有BuckleScript绑定,那么您很幸运。
    5. N / A
    6. ReasonML编译非常快。

答案 3 :(得分:9)

(只是一个音符)

将所有实际问题放在一边;

ML语言家族基于称为System-F的类型理论,例如,Purescript和Haskell也使用这种语言。

打字稿缺乏如此完善的基础,而是使用具有许多特殊位的新实验型系统(我什至不确定它是否“形式化”)。

因此,从表面上看,TS的方法似乎是“实用的”,但它引入了必要的更多复杂性。系统F具有构成系统的少量规则,它非常笼统,但更容易推断出TS的“理论”。少即是多。

此外,学习System-F所花费的时间也是永恒的,可以转化为其他更强大的语言,例如Purescript。

答案 4 :(得分:5)

非常不同。

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

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

  • 如果您想编写typesafe JavaScript ,则可以选择TypeScript。

  • 如果您想编写可以编译为JavaScript的typesafe 某种语言,那么ReasonML是众多选项中的一种。 ReasonML案例中的某种语言是OCAML。

更多

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

答案 5 :(得分:1)

Reason ML带有功能性第一学堂,如果您以这种思维定势,那就去了。而打字稿可以做fp并且也有很好的社区支持。几乎所有流行的库都有打字稿类型。我更喜欢使用fpts(https://github.com/gcanti/fp-ts/blob/master/README.md)。它在打字稿中提供了fp的所有优势,其中还包括运行时检查。尽管类型构造函数在ts中是一个很大的小姐。如果可以接受,请选择ts。