TypeScript的竞争者有哪些

TypeScript 的目标是为人们提供编写大型 JavaScript 项目并对后期维护有信心的工具。JavaScript 本身没有的语法支持表示每个标识符的类型，除非运行 JavaScript 并在运行时进行检测。为了解决这个问题，TypeScript 添加了额外的语法。 所以，如果说我们的目标是作为工具提供支持，那么在这个领域有少数几个竞争者是 TypeScript 无法与之竞争的

• ESLint 和 TSLint：与 TypeScript 的定位相同，它们都是用来突出代码中可能出现的错误，只是没有为检查过程添加新的语法。两者都不打算作为 IDE 集成的工具运行，而且 TS 和 TS/ESLint 经常会说那些对项目没有意义的特性“是对方的领域”。在现代代码中，TS/ESLint 的存在使得TypeScript 可以做更少的检查，这些检查并不适用于所有代码库。虽然有一些功能重叠了，但可以把它们作为很好的补充工具。

• CoffeeScript：嘿，TypeScript 是 2012 年发布的！CoffeeScript 和 TypeScript 的区别在于CoffeeScript 想要改进 JavaScript 语言，比如给 JavaScript 添加一些特性。这意味着要了解CoffeeScript 与其输出的 JavaScript 的区别。随着时间推移，CoffeeScript 的最佳理念反而将其变成了另一个 JavaScript，人们为几乎成为了 JavaScript 的 CoffeeScript 感到困扰。

• Flow：这是 Facebook 的 JavaScript 类型检查工具和 IDE 工具语言。就像 TypeScript 一样，Flow为 JavaScript 添加了一些额外的语法支持，让你拥有了一个更加丰富的类型系统，然后在编译时再将其删除。当我刚开始写 JavaScript 时，Flow 是我最先使用的工具，因为它更接近标准的JavaScript。Flow是一个很棒的类型系统，它与 TypeScript 有着不同的目标。任何看不见的类型层系统都必须不断做出“正确”或者“感觉足够正确”的决定，Flow 的目标是“正确”（译者注：Flow 偏向于soundness[6]，在类型判断中更加悲观），而 TypeScript 的目标是“感觉上大部分情况都是正确的”译者注：而 TS 官方声称 TS 不是类型完备的[7]，允许 unsound 行为，偏向于completeness，在类型判断中更加乐观）。鱼和熊掌不可兼得，完备的类型推导、良好的开发体验和完美的 JS 协同（Perfect JavaScript Interop）只能取其二。

那么，为什么大多数开源 Flow 代码库最终都迁移到了 TypeScript 呢？在我看来，很大程度上是由两个团队不同的侧重点决定。Flow 是为了维护 Facebook 的代码库而建立的，而 TypeScript 是作为一种独立的语言建立的。这里有两个证据可以证明：

• Facebook 的代码库是一个不能被分割的巨大的 monorepo，而 Flow 团队为了使类型运行在这样的大代码库[8]下做了大量令人难以置信的工作[9]。另一方面，TypeScript 可以说是“为构建小代码库服务（use projects to make sets of smaller codebases）”，因为这符合人们在开源社区中编写JavaScript 模块的方式。我认为这么说很合理，TypeScript 不能像 Flow 一样运行在 Facebook 的代码库上，它要么需要大量重写 Facebook 的代码来构建项目，要么需要对 TypeScript 进行大量修改，这可能会影响到 TypeScript 整体开发者的体验。

• 对比 DefinitelyTyped 和 Flow 对类型的做法，TypeScript 团队会轮值一名编译器工程师为 DefinitelyTyped 支持我们的构建工具，并帮助管理社区。而 Flow，它几乎完全由社区维护。DT现在规模更大了，因为它们一直致力于非 Facebook 代码的开发，这将很难获得 Flow 团队的资金支持。

微软给 TypeScript 在内部创造的独立环境让它可以自由专注于工具开发和整个生态系统的维护，而不是只专注于解决某个特别困难的问题。这让 TypeScript 团队能够与许多人合作，不断发布社区想要的功能。随着时间的推移，我猜想因为外部的需求增长放缓，Flow 团队越来越难为社区工作分配时间。这就形成了一个恶性循环。这使得 Flow 今天不再是 TypeScript 的直接“竞争者”，而是一个关于如何从不同的角度，使用不同的约束去解决类似的问题的有趣视角。