全文意译，如有误导，请放弃阅读。原文为《A Proposal For Type Syntax in JavaScript》
TL; DR
- 该提案的主要内容是：在 JavaScript 语法中有选择地加入 Typescript 类型系统的子集，但是同时 javascript 运行时能够忽略和擦除这些类型语法。
- 该提案没有倡导的是：不要在运行时给 javascript 加入类型检查环节，因为一旦这么干了 ，就会带来各种问题。比如：运行时性能问题，与现有 TypeScript 代码的兼容性问题，阻碍类型检查领域创新问题等。
今天，我们很高兴地宣布我们支持并与第三方共同合作来推进 新的 Stage 0 提案，以此为 JavaScript 带来可选和可擦除的类型语法。因为这种新语法不会改变周边代码的运行方式，所以它可以有效地充当注释。我们认为这有可能使 TypeScript 更容易、更快地用于各种规模的开发。我们想谈谈我们为什么想要在 JavaScript 中加入类型，以及这个提案是如何在高层次上运作的。
背景
我们的团队最近在 JavaScript 世界中看到的一个趋势是「需要更快的迭代时间和减少构建步骤」。换句话说，“让它更快，让它更简单”。
在某些方面，这已经在发生。由于常青浏览器（什么是常青浏览器？）的成功（主流浏览器很快就实现了 ECMAScript 的较新特性），开发人员不用过多地编译较新版本的 JavaScript 来兼容旧的运行时。在某种程度上，打包流程也是如此——大多数浏览器都内置了对使用 ES 模块的支持，因此打包流程已经可以被视为一个优化环节，而不是一个必要环节。类似情况越来越多，那么 TypeScript 需要思考如何跟上这种节奏。
如果我们回到 2012 年 TypeScript 首次发布时，JavaScript 世界与今天的完全不同了！在那个时候，只有少部分的浏览器进行了快速迭代和频繁发布，其他的浏览器却没有这么做。在那个时候，还不清楚我们会被旧版本的 Internet Explorer 卡住多久，这导致打包器和编译器等工具得以广泛流行。给 JavaScript 添加构建步骤的时代，这也是 TypeScript 够真正蓬勃发展得原因——毕竟，既然你需要编译你的 JavaScript，为什么不顺带编译掉你的类型呢？但是，如果我们上面提到的那些趋势继续下去（很多新的 ECMAScript 特性可以直接跑在浏览器里面），编译你的类型可能是编写 TypeScript 和运行它之间的唯一需要做得事情。实际上，我们不希望自己成为良好开发体验的唯一障碍！
在某些方面，我们的 JavaScript 支持弥补了这里的差距，如果您使用 Visual Studio 或 Visual Studio Code 之类的编辑器，也许您已经看到了这一点。今天，您可以在编辑器中创建一个 .js 文件，并开始以 JSDoc 注释的形式添加类型。
/**
* @param a {number}
* @param b {number}
*/
function add(a, b) {
return a + b;
}
复制代码因为这些只是注释，所以它们根本不会改变你的代码运行方式——它们只是一种自文档的形式，但是 TypeScript 却能够通过它来为你提供「代码自动补充」、「重构」等更好的 JavaScript 编辑体验。您甚至可以通过在文件顶部添加 // @ts-check 注释来添加类型检查，或者通过开启了 checkJs 开关的 TypeScript 编译器来运行这些文件。这个特性使得在没有构建步骤的情况下取赢取一些 TypeScript 体验非常方便，你可以将它用于小脚本、基础简单的网页、Node.js 中的服务器代码等。
不过，你会注意到这有点冗长——我们喜欢在编写 JavaScript 时的简便，但我们错过了 TypeScript 为编写类型时提供的便利性。
小孩才会去做选择，大人两者都要。所以，假如我们能同时拥有两者呢？如果我们可以在 javascript 中拥有像 TypeScript ，但是同时它又可以像 js 注释一样可以被忽略的语法，那将会怎样呢？
function add(a: number, b: number) {
return a + b;
}
复制代码我们的团队相信这里有很大的潜力，本月我们希望在向 ECMAScript 标准委员会 TC39 提交的提案中正式指出它！
这将如何工作？
当我们过去被问到“类型何时出现在 JavaScript 中？”时，我们都是犹犹豫豫，不知道怎么回答。从历史上看，如果你拿这个问题去问开发人员他们对往 JavaScript 中加入类型有什么想法，你会得到许多不同的答案。有些人认为类型应该被完全忽略，而另一些人则认为它们应该具有某种意义——可能它们应该强制执行某种运行时验证，或者它们应该是可自省的，或者它们应该作为引擎优化的提示等等。但在过去的几年里，我们看到人们更多地趋向于一种与 TypeScript 发展方向一致的设计——即类型在运行时被完全忽略和可擦除的语法。当我们核心团队之外的几位 JavaScript 和 TypeScript 开发人员再次向我们提出一项名为“类型作为注释”的提案时，这种融合以及 TypeScript 的广泛使用让我们更加自信。
这个提案的想法是，JavaScript 可以为引擎完全忽略的类型创建一组语法，但 TypeScript、Flow 和其他工具可以使用这些类型语法。这使我们能够保留您对 TypeScript 的喜爱——它的类型检查和编辑体验——却又同时消除开发中构建步骤的需要。
因此，在编写和运行代码时，开发人员的工作流看起来会有些不同。
同时，编写代码和类型检查将保持不变。开发人员可以在支持 TypeScript 的编辑器中获得即时类型检查反馈，在命令行上运行 TypeScript，并将 TypeScript 添加为他们的 CI 任务的一部分。最大的不同在于，因为我们不需要构建步骤，我们将大大降低 JavaScript 开发人员体验类型和优秀工具链之强大的门槛。
为了实现这一点，JavaScript 至少需要为变量和函数的类型注释、参数和类成员的可选修饰符 (?)、类型声明（接口和类型别名）和类型断言运算符（as 和 ! )等添加相应的语法——所有这些都不会影响周边代码的运行方式。
诸如可见性修饰符（例如public、private和protected）之类的东西也可能在范围内；但是，枚举（enums）、命名空间（namespaces）和参数属性（parameter properties）将超出此提案的范围，因为它们具有可观察的运行时行为。这些功能可以根据反馈作为单独的 ECMAScript 功能以提案的方式提出，但我们当前的目标是支持 TypeScript 的一些大型子集，我们认为这些子集可能是对 JavaScript 的有价值的补充。
通过这种划分，我们为类型检查器腾出了空间，使得它可以在所需要的新语法上进行创新。这确实意味着引擎会愉快地运行具有无意义类型的代码，但我们相信类型检查器可以（并且应该）是规范性的，并且执行比运行时更严格的约束。结合起来，这使得类型语法可以在不同的检查器之间进行自定义，或者如果有人认为他们对 TypeScript 或任何其他类型检查器不满意，则可以完全不在 javascript 中编写了类型代码。
我们没有倡导的东西
我们觉得值得强调的一点是，这个提案中没有去倡导的东西是什么。
我们的团队不建议在每个浏览器和 JavaScript 运行时中加入 TypeScript 的类型检查这么一个环节——我们也不建议在浏览器中加入任何新的类型检查。我们认为这样做会给 JavaScript 和 TypeScript 用户带来同样的问题，因为一系列问题：运行时性能问题、与现有 TypeScript 代码的兼容性问题以及阻碍类型检查领域创新问题。
相反，我们只是提出了在 JavaScript 中加入与 TypeScript 兼容并受其启发的语法，它可以被任何类型检查器使用，但会被 JavaScript 引擎忽略/跳过。我们相信这种方法对每个人来说都是最有前途的，并将继续让 TypeScript、Flow 和其他人继续进行类型系统的创新。
接下来，我们会干什么？
鉴于这一切，我们将与提案的共同拥护者一道，在Bloomberg 的 Rob Palmer 和 Igalia 的 Romulo Cintra 的支持和指导下，计划在即将于 2022 年 3 月举行的 TC39 全体会议上提交第 1 阶段的提案。
达到第 1 阶段意味着标准委员会认为在 ECMAScript 加入类型语法是值得一试的想法。这事肯定不是板上钉钉的—— TC39 委员会中有许多有价值的不同观点，我们确实预料到遭受一些怀疑。像这样的提案会收到很多反馈和适当的审查。在此过程中可能涉及大量设计更改，并且可能需要数年才能产生结果。
但是，如果我们完成这一切，我们就有机会对 JavaScript 世界做出最有影响力的改进之一。我们对此感到兴奋，我们希望你也是。
如果您有兴趣了解更多关于具体细节和当前方向的信息，请前往提案库。我们期待听到您的声音和看到你的想法！
最后，TypeScript 团队和该提案的拥护者们要感谢所有从事 prior art的人，以及通过参与讨论来对该提案想法伸出援助之手的贡献者，特别是帮助宣传这个想法的 Gil Tayar。我们很高兴能成为这样一个充满激情的社区的一员！