本文经作者受权，翻译总结自 TypeScript Team 的成员 orta 的集体博客《Understanding TypeScript’s Popularity》。

原作者: orta

原文链接：https://orta.io/notes/js/why-typescript

翻译：ycaptain

TypeScript 是一种十分受欢迎的 JavaScript 语言扩大。它在现有的 JavaScript 语法之上退出了一层类型层，而这一层即便被删除，也丝毫不会影响运行时的原有体现。许多人认为 TypeScript “ 只是一个编译器 ”，但更好的了解其实是把 TypeScript 看作两个独立的零碎：编译器（即解决语法的局部）和语言工具（即解决与编辑器集成的局部）。通过独立对待这两个零碎，就能够失去可能解释咱们之前所做决策的两个重要视角。

在 npm 上，TypeScript 的下载量每年都在翻倍。现在（博客公布于 2021 年 4 月 14 日），它的每周下载量约为 2000 万次。而在去年 4 月，这一数字约为 1000 万次。它仍放弃着高速增长的趋势，没有任何放缓的迹象。

1. 咱们是怎么令它变得如此受欢迎的？

从 2.0 版本开始，TypeScript 每两月定期公布一个 release。然而当初咱们放缓了公布的节奏，改为每三个月公布一次。其中咱们会花一个月编写新 features 并公布 beta 版本，剩下两个月对 beta 版进行测试和 bug 修复，这使得后续的公布更加稳固。

1.1 大事件工夫线

在我看来，上面这些都是让 TypeScript 一直冲破风行极限的大事件：

• 2014 – 重写 TypeScript，TS v1.1 – TypeScript 上线后，咱们从新 review 了 TypeScript 的代码库，想明确了它到底是什么，因而咱们摈弃了原有的代码，并以函数式格调从新编写（区别于原来具备可变个性的类）– 这套架构始终沿用至今，它可能在极少产生变更的过程中稳固高效地长时间运行。有人曾提到 TypeScript 的前身是 C++ 编写的，这点我不能确定其真实性。
• 2015 – Angular 采纳 TypeScript，TS v1.5 – 过后 Google 正在思考为 Angular 构建他们本人的语言，而不是抉择应用 TypeScript。为了让 TypeScript 可能被纳入思考，TypeScript 突破了它的其中一条根本规定：不要过早实现 TC39。就这样，TypeScript 反对了 experimentalDecorators。即便这一个性六年后还没有被增加到 JavaScript 中，对于所有参加开发的人来说，这个后果也是齐全值得的他们接受这项技术债权的。
• 2015 – 在 TypeScript 中反对 JSX，TS v1.6 – 这时 React 也成长为了一个十分受欢迎的 UI 库。而 React 应用 JSX：一种能够在 JavaScript 中高效地编写 HTML 的 JS 语言扩大。TypeScript 对 JSX 的反对使得其他人能够进行 TypeScript 对 React 的反对（由 @types/react 保护，而不是内置于 TypeScript 中）
• 2016 – 未定义类型，基于控制流进行动态类型剖析 – TS v2.0 – 在 1.4 版本公布的性能 union types 的根底上，TypeScript 反对了 undefined 和 null 类型。这使得类型零碎能够真正对大部分 JavaScript 代码建模。与此同时，代码控制流剖析使得 if 语句及其它的用户代码都能影响到变量在不同地位的类型剖析后果。
• 2016 – 拥抱 DefinitedTyped, TS v2.0 – DefinitelyTyped 是一个由志愿者们编写的业余我的项目。过后有一些其它相似 DefinitelyTyped 的零碎，TypeScript 团队采纳了 DefinitelyTyped 并将 @types/x 的概念融入他们的编译器当中。在采纳和保护 DefinitelyTyped 的过程中，TypeScript 团队进行了认真的测试并改良了工作流，这帮忙它成为了 GitHub 上最沉闷的 Repo 之一。对于 DT 的故事值得一读。
• 2016 – 反对 JavaScript, TS v2.3 – 只管过后曾经有一些语言工具链反对 JavaScript 我的项目，对 JSDoc 的反对使得 JavaScript 我的项目即便不应用 TypeScript 也能取得它的一些益处。这不仅开启了 JavaScript 向 TypeScript 迁徙之路，还为已存在的 JavaScript 我的项目提供了工具反对。
• 2018 – 在 Babel 中减少 TypeScript 反对, Babel 7 – 这是 TypeScript 成为代码库归宿的终点。在 Babel 中减少 TypeScript 反对给 TypeScript 减少了一些束缚（译者注：isolated modules），但这是值得的。从此 TypeScript 不再须要从 eslint 迁徙到 tslint 的简单的迁徙过程，而是像勾选一个复选框一样轻松。
• 2018 – Composite Projects, TS v3.0 – 有许多形式能够解决大规模源码库，TypeScript 的解决形式就是 Composite Projects。通过应用 .d.ts 文件作为我的项目的边界，你能够在一个单体代码库内保护很多 TypeScript 子项目。这节俭了工夫和内存，最重要的是这使得你能够将其扩大成十分大的代码库。
• 2019 – Optional Chaining, TS v3.7 – 尽管这个列表中还脱漏了一些更大的语言个性，然而与 TC39 联合的完满个性 Optional Chaining 使得人们对 TypeScript 反对十分兴奋。作为 JS 生态系统和工具的优良参与者，将可选链个性退出 JavaScript 的过程是一个 TypeScript 对于本身预期定位的完满例子。TypeScript 应该多做这类我的项目。
• 2020 – esbuild / swc / sucrase – 这些新的编译器和 JavaScript 运行时从第一个版本就反对 TypeScript 语法，任何基于这些工具的我的项目都能够间接应用 TypeScript。TypeScript 语法在 .ts 文件中间接启用进一步使得它作为 JavaScript 的内置扩大合法化。
• 2020 – 重写用户文档 – 重写文档是我的工作，所以不要齐全置信这部分形容，然而这些年 TypeScript 的文档始终很单薄。我与很多编译器团队里的老人一起从新编写面向用户的文档，并为他们提供一个帮忙了解 TypeScript 的在线编辑器。这是对于答复语言问题的第一步，优良的文档能够让编译器团队将注意力集中在编译器上。

我的认识：TypeScript 之所以风行，是因为它一直通过工具（DT / — isolatedModules / JSDoc）升高入门门槛，与其它工具和组织单干（Babel / TC39），并通过渐进式的形式展现工具和类型平安在 JavaScript 中的价值。现在，那些写 JSDoc 的人实际上就是 TypeScript 用户，就像应用 –strict 的人一样。

1.2 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，在类型判断中更加乐观），而 TypeScript 的指标是“感觉上大部分状况都是正确的”（译者注：而 TS 官网宣称 TS 不是类型齐备的，容许 unsound 行为，偏差于 completeness，在类型判断中更加乐观）。鱼和熊掌不可兼得，齐备的类型推导、良好的开发体验和完满的 JS 协同（Perfect JavaScript Interop）只能取其二。

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

1. Facebook 的代码库是一个不能被宰割的微小的 monorepo，而 Flow 团队为了使类型运行在这样的大代码库下做了大量令人难以置信的工作。另一方面，TypeScript 能够说是“为构建小代码库服务（use projects to make sets of smaller codebases）”，因为这合乎人们在开源社区中编写 JavaScript 模块的形式。我认为这么说很正当，TypeScript 不能像 Flow 一样运行在 Facebook 的代码库上，它要么须要大量重写 Facebook 的代码来构建我的项目，要么须要对 TypeScript 进行大量批改，这可能会影响到 TypeScript 整体开发者的体验。
2. 比照 DefinitelyTyped 和 Flow 对类型的做法，TypeScript 团队会轮值一名编译器工程师为 DefinitelyTyped 反对咱们的构建工具，并帮忙治理社区。而 Flow，它简直齐全由社区保护。DT 当初规模更大了，因为它们始终致力于非 Facebook 代码的开发，这将很难取得 Flow 团队的资金反对。

微软给 TypeScript 在外部发明的独立环境让它能够自在专一于工具开发和整个生态系统的保护，而不是只专一于解决某个特地艰难的问题。这让 TypeScript 团队可能与许多人单干，一直公布社区想要的性能。随着工夫的推移，我猜测因为内部的需要增长放缓，Flow 团队越来越难为社区工作调配工夫。这就造成了一个恶性循环。这使得 Flow 明天不再是 TypeScript 的间接“竞争者”，而是一个对于如何从不同的角度，应用不同的束缚去解决相似的问题的乏味视角。

2. 将来

2.1 对 TypeScript 的将来怎么看？

目前妨碍人们应用 TypeScript 的最大阻碍是它须要构建工具。我认为类型语法不太可能被退出 JavaScript 中，然而在 JavaScript 中“用正文的形式定义类型”的可能性十分大。

这个想法是为 TypeScript 这样的类型零碎创立一套语法，然而不定义 JS 运行时会产生什么。

const a: string = "1234"

// 将会变成这样
const a/_: string _/ = "1234"

// 传入 JS 引擎 

在这个例子中，JS 引擎会晓得 : string 是一个类型正文，在 = 处结尾。这理论的工作形式是简单的，须要工夫来弄清楚。然而，让 TypeScript 能在 JavaScript 中“原生地”运行将升高它被应用的阻碍。它会像 Babel 增加 TypeScript 反对时一样对 TypeScript 施加一些束缚。但我感觉这是值得的。

Deno 是一个打消所有 TS 阻碍的要害例子，它通过运行一个 Rust 编写的工具，可能十分疾速地将 TS 编译到 JS，模仿了以后 JavaScript 引擎对原生 TypeScript 的反对。

2.2 现在的竞争者

• JetBrins WebStorm – 这是一个有高级 JavaScript 工具反对的 IDE。他们有本人的引擎用于重构、代码流剖析并对 JavaScript 语法进行查看。这很好，JetBrains 在他们所有的 IDE 上都做了扎实的工作。我过来常常应用 AppCode 解决 iOS 的工作。当你有一个 TypeScript 我的项目时，WebStorm 会将 TypeScript 的语言工具和本人的工具混合在一起，这对你来说是双赢的。
• 编译到 JS 的语言 – 目前的例子有 Elm，ReScript，KotlinScript，这些语言的外围指标是与 JavaScript 交互。对于 TypeScript 来说，这些都是很乏味的语言，它们有一个洁净的环境来实现类型零碎 —— 也就是，没有 JS 包袱。作为竞争对手，它们偏向于更细分的市场，因为它们的外围不是 JavaScript，并且社区也被从 CoffeeScript 迁徙所困扰过。
• WASM – 我听到 WASM 作为 TypeScript 竞争者的观点是，WASM 能够作为语言取代 JS 管制浏览器 DOM。拥护这一观点的人普遍认为，WASM 没有 DOM 绑定，而且可能永远不会有。TypeScript 蕴含了 JavaScript 的毛病，如果你在 JavaScript 运行时中退出过 WASM 的话，你简直总是会更加喜爱它。也就是说，AssemblyScript 在这方面做了一些很好的工作。兴许把 WASM 想成 JSON 会更好，它是另一个组成我的项目的工具，不太可能成为 JavaScript 的竞争者，除非 WASM 和 DOM 的交互方式有所扭转。
• 编译到 WASM 的语言 – 比方 Rust，Go，Swift，等其它能够编译到 WASM 的语言。这些语言都可能占据 TypeScript 目前作为工具和 web 外围构建模块的地位，不过世事难料，谁晓得会怎么样呢？这些语言可能提供各种不同的根本类型，并且基于不同的指标从头构建。如果 WASM 和 WASI 最终获得成功，那么我认为将会与平台相干（想想 apps 等性能实现），看看它们的倒退方向会很乏味。说心里话，它们不会是 TypeScript 的竞争者，而是 JavaScript 的。

2.3 TypeScript 怎么看它在生态中的地位？

TypeScript 心愿在类型零碎和编辑器工具畛域进行翻新。咱们领有在支流编程语言中表达能力最强的类型零碎之一。

TypeScript 最后被创立时，对 JavaScript 进行批改的流程和当初十分不同，所以 TypeScript 中有一些个性实际上是 TC39 的畛域，但依然须要向后兼容。这些个性可能在 JavaScript 中存在很多年，并且通过了屡次迭代，这意味着 TypeScript 必须保护一个特定语言个性的两种版本。

所以咱们的指标是成为 TC39 JavaScript 语言委员会的优良成员，就编辑器反对的语言个性进行反馈，反对 TypeScript 用户想要看到的个性。通过这种合作形式，TC39 管制了 JavaScript，TypeScript 也反对他们。

2.4 TypeScript 怎么看它的受众？

TypeScript 的受众次要有:

• JavaScript 用户（作为语言工具）
• JS + JSDoc 用户（作为语言工具）
• TypeScript 用户（作为编译器，语言工具）
• TypeScript 严格模式（作为编译器，语言工具）

尽管我的项目应用 babel / swc / sucrase / esbuild 等工具构建时，tsc 是可选的，然而下面的几种受众依然能够在每次或至多每两次 TS 版本公布中取得新个性（译者注：babel、esbuild 等会更新反对 TS 新个性。可能是 TS 团队间接去这些我的项目里做，也可能会在没有 tsc 的状况下为这些我的项目提供个性，比方通过 vscode。在 TS roadmap 中能够理解更多公布打算）。

2.5 TypeScript 是如何跟踪 JS 生态的？

团队从以下几个形式听取反馈：

• GitHub issues 有继续一直的评论洪流
• 微软外部团队要求提供个性，或者要求咱们帮忙调试他们迟缓的代码库
• 通过 Gitter 或者 TypeScript 社区的 Discord 与社区建立联系
• 通过微团的外部工具对想法 / 设计进行用户测试
• 与 VS Code 有着十分严密的分割，许多语言工具的反馈都来自于他们
• 咱们会浏览每一条 @ TypeScript 团队的推特
• 咱们会跟踪迁徙到 TypeScript 和从 TypeScript 迁走的博客文章
• 咱们会跟踪行业考察和编程语言概述