TypeScript 与 Flow 的对比

TypeScript 与 Flow 的对比

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

TypeScript 与 Flow 的对比

这并非严格的比较，更像是一种反思。在我看来，Flow 和 TypeScript 有些相似之处，两者都不完美，但都比无类型的 JavaScript 好。它们在很多方面有所不同，但在简单的用例中却很相似。

我正在做一个关于 Redux、类型系统、有限状态机、副作用等方面的实验。我想试试 io-ts，它有 TypeScript 的类型定义（实际上它就是用 TypeScript 写的），但没有 Flow 的类型定义（Flow 的类型定义在 v1 版本之前就被弃用了）。虽然可以更新旧的 Flow 类型定义，但我决定直接用 TypeScript 重写整个应用程序。这篇文章主要是对这个过程的反思。

react-scripts-ts

react-scripts-ts 自带 tslint 而不是 eslint，并且其配置是公开的，这违背了 Create React App 的理念，因为它应该是零配置设置。

默认的 tslint 配置太死板了。它居然要求我按字母顺序排列属性。说真的，谁有时间做这个？我希望代码检查工具能指出错误，它的目的是帮助我，而不是给我增加工作量。我喜欢 CRA 的方法，eslint 会指出一些明确的错误，而格式化则留给 prettier 处理。

代码检查器错误会直接显示为错误，而不是警告。有时这些错误会“卡住”——我进入错误状态后修复了错误，但只有重启项目后错误才会消失。我不得不禁用大部分 tslint 配置，体验非常糟糕。我不想花时间配置它，我只想做一些原型设计。

看起来（但我没有实际测量），响应周期（从我点击保存按钮到更改传播到浏览器所需的时间）比使用 Flow 的 CRA 慢。我不确定这是 TypeScript、tslint 还是 react-scripts-ts 导致的。

实际上，TypeScript 与 Flow 的对比

顺便提一下，有些人喜欢把 TypeScript 和 Flow 做比较。在我看来，它们简直太相似了。我来解释一下原因——我内心一直在思考 TypeScript 和 Flow 的区别：

• Flow 的设计理念是健全性，而 TypeScript 的设计理念是“实用”的类型系统（我其实并不认同这种理念，他们似乎根本不想要健全性）。
• 是的，Flow 的实现存在一些错误，它虽然声称自己是健全的，但实际上并非如此。如果您需要健全的代码，请使用 ReasonML（OCaml）。此外，Flow 有时会放弃类型检查，存在所谓的“类型未覆盖”代码区域，您需要使用flow-coverage-report 来查看代码覆盖率。
• 好的，但是流程有所有这些实用类型，例如$ObjMap，$Call等等。
• 是的。TypeScript 最近也添加了很多类似的功能。参见utility-types和flow-to-typescript。
• 然而，这在 TypeScript 中无法实现。$ObjMap
• 谁在乎呢。字面量不可能同时保证字符串和对象类型的完全一致。

const a = "b";

• 在 Flow 中，类型a是字符串；在 TS 中，类型是"b"字符串字面量（这是不可能实现的a[0]="c"）。
• 我听说 Flow 即将支持精确的对象类型。
• 最后，他们从 TypeScript 中复制了它。
• TypeScript 借鉴了 Flow 的理念typesVersions，现在我们需要等待Flow 也把这个理念借鉴回来。
• Facebook 使用 Flow，所以 React 与 Flow 自然契合，而使用 TS 则需要一些技巧。
• 好的，但是TS也拥有最多的类型签名。
• 我们可以使用一些Flowgen 工具将其转换为 Flow。
• 流程有索引
• TS拥有单片眼镜、io眼镜等等。
• TypeScript 的编译器标志是个糟糕的设计，因为每个项目对类型严格程度的要求都不一样。类型签名也是如此，你永远无法预知它们的严格程度。
• TS拥有更大的社区和更开放的开发周期。而Flow的开发则是在闭门进行。

这种争论没完没了。所以我自己得出结论：Flow 和 TypeScript 差不多。两者都不完善，都不理想。但我还是会选择 TypeScript 或 Flow，而不是纯 JavaScript。

别跟我提 ReasonML/BuckleScript。

照片由 Matt Jones 拍摄，来自 Unsplash

本文是系列文章之一。请在推特和GitHub上关注我。