TypeScript的未来

对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 的支持。

如今的竞争者

• JetBrains 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 的。

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

TypeScript 希望在类型系统和编辑器工具领域进行创新。我们拥有在主流编程语言中表达能力最强的类型系统之一。 TypeScript 最初被创建时，对 JavaScript 进行修改的流程和现在非常不同，所以 TypeScript 中有一些特 性实际上是 TC39 的领域，但仍然需要向后兼容。这些特性可能在 JavaScript 中存在很多年，并且经过了多次迭代，这意味着 TypeScript 必须维护一个特定语言特性的两种版本。 所以我们的目标是成为 TC39 JavaScript 语言委员会的优秀成员，就编辑器支持的语言特性进行反馈，支持 TypeScript 用户想要看到的特性。通过这种协作方式，TC39 控制了 JavaScript，TypeScript 也支持他们。

TypeScript 怎么看它的受众？

TypeScript 的受众主要有:

• JavaScript 用户（作为语言工具）

• JS + JSDoc 用户（作为语言工具）

• TypeScript 用户（作为编译器，语言工具）

• TypeScript 严格模式（作为编译器，语言工具）

虽然项目使用 babel / swc / sucrase / esbuild 等工具构建时，tsc 是可选的，但是上面的几种受众仍然可以在每次或至少每两次 TS 版本发布中获得新特性（译者注：babel、esbuild 等会更新支持 TS 新特性。可能是 TS 团队直接去这些项目里做，也可能会在没有 tsc 的情况下为这些项目提供特性，比如通过vscode。在 TS roadmap[10] 中可以了解更多发布计划）。

TypeScript 是如何跟踪 JS 生态的？

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

• GitHub issues 有持续不断的评论洪流

• 微软内部团队要求提供特性，或者要求我们帮忙调试他们缓慢的代码库

• 通过 Gitter 或者 TypeScript 社区的 Discord 与社区建立联系

• 通过微团的内部工具对想法 / 设计进行用户测试

• 与 VS Code 有着非常紧密的联系，许多语言工具的反馈都来自于他们

• 我们会阅读每一条 @ TypeScript 团队的推特

• 我们会跟踪迁移到 TypeScript 和从 TypeScript 迁走的博客文章

• 我们会跟踪行业调查和编程语言概述