使用 ES6 + Flow 代替 TypeScript

Question

我正在为一个 JavaScript 应用程序建模。此应用程序的主要功能是使用 REST API 来配置和显示具有一些自定义输入类型的表单。我正在考虑使用TypeScript 来利用类型和类。但是经过一些 Google 搜索后，我意识到我可以使用 JavaScript ES6 + Flow（也许还有 Babel）得到非常相似的结果。

我的问题是：

• 这两种方法真的很相似还是我搞砸了？
• 在选择 ES6 + Flow 还是 TypeScript 时，我应该考虑哪些因素？

感谢您的帮助。

Answer 1

静态类型系统帮助

我是静态类型语言的忠实粉丝，尤其是 Haskell。我已经涉足 TypeScript 和 Flow。静态类型技术的吸引力在于在编译器（或类似的工具）的帮助下构建更好的代码。通过改进的验证工具，我可以澄清我的想法，以获得更复杂、更不言而喻的设计。这是代码的质量，在重构和维护时也会得到回报。这就是好处。

成本是选择差异化的地方最

在这个选择中，成本是关键所在，因为这是 Flow 和 TypeScript 之间最大的区别所在。 Haskell 的强大之处在于推断类型的能力。虽然使用类型签名注释函数定义是最佳实践，但这不是必需的。

此外，这是关键，我在编写代码时最依赖类型推理引擎，即，在试图找出设计的最佳方法类型签名。一旦我有了“那种类型”的代码，我实际上就不需要静态类型的容量......完成工作，按照编译器编译器通过剥离所有类型信息所做的工作。

当我最需要静态类型的信息时，无法推断类型是我在使用 TypeScript 时遇到的最大问题。当我最需要字体容量时，我可能会在不经意间犯错误，而没有任何关于如何在最需要它时解决它的指导。此外，由于无法选择让编译器推断信息，我增加了我的工作量，我以我知道不必要的方式增加了问题的复杂性。这就是推理引擎的关键所在。它减少了用户必须是明确的。它在设计我的代码时启用了一个线性过程（因果关系）。

打孔线

好处的来源是明确定义的（类型帮助）。多少收益可能取决于项目。以我的经验，有更多的项目使用 Flow 使用静态类型方法的收益超过成本。

关于 Flow 的设置，我已经在使用转译器，发现需要的额外配置是名义上的。这种配置方法的好处是能够逐步使用该技术，并且仅在您认为最需要类型驱动“指导”的项目中使用。

最后，我没有提到使用 Flow 的语法优势。已经够糟糕了，我不得不跟踪各种风格的 JS（所有好的变化），使用 Flow 我避免了我认为与 JS 的 TypeScript 有很大的不同。

-E

Answer 2

免责声明：我在 Flow 团队工作。

总的来说，我认为 Flow 更注重可靠性，而 Typescript 更注重易用性。因此，Flow 将禁止可能导致运行时错误的事情，而 Typescript 在某些情况下决定在实践中某些行为不太可能导致错误，并且防止不太可能的错误不值得给开发人员带来不便。

这是一个具体的例子：

type Foo = {
    x: string;
}

type Bar = {
    x: 'foo';
}

const b: Bar = { x: 'foo' };

const f: Foo = b;

f.x = 'asdf';

此代码不正确 -- b.x 现在是 'asdf'，尽管类型说它应该是 'foo'！

Typescript 允许这样做。 Flow 抱怨一个令人困惑的错误。

(typescript playground) (try flow)

关于工具，Typescript 胜出，毫无疑问（尽管我这么说，作为主要负责将 Flow 集成到 Nuclide 的人）。设置过程很简单，一切正常。对于 Flow，你需要安装和配置 Babel（因为 Flow 不是编译器，你需要一些东西来去除类型）。对于 Typescript，您只需下载 VSCode 即可获得编辑器支持，您就完成了——您甚至不需要单独下载 Typescript。对于 Flow，如果要走推荐路线，需要安装 Atom+Nuclide 并单独下载 Flow。设置完成后，Flow 编辑器支持运行良好，但初始设置非常耗时。

我没有使用足够多的 VSCode+Typescript 来准确地比较它们，但我知道很多人对它非常满意，并且基于我有限的经验，它非常精致。功能集也更大——例如，Typescript 支持自动重构。

Typescript 的 DefinitiveTyped（一组库的类型定义，因此您可以在保持类型安全的同时使用 npm 模块）比 Flow 的类似 flow-typed 更大且更成熟——尽管 flow-typed 正在增长。