原文：A Proposal For Type Syntax in JavaScript
tac-announcement-today-proposed.svg
正文：

A Proposal For Type Syntax in JavaScript

JS中增加类型语法的提议

今天我们很激动的宣布我们的支持和合作关于a new Stage 0 proposal ，给JS增加可选的和可删除的类型语法。因为这个语法不会改变周围代码的运行方式，但是它却有效的扮演类似评论一样。我们认为这有潜力使TS更容易和更快的在开发中使用在任何规模。我们很乐意去讨论我们为什么追求这个，这个提议是如何工作的在一个很高的水平上。

Background(背景)

一个最近的趋势在我们团队在JS世界，是对更快迭代时间的需求和更少的构建步骤。换言之，’让他更快，让他更简单’。

在某种程度上，这已经发生了。感谢经久不衰的浏览器的成功，开发者可以避免编译老的版本的JS运行在老的运行时上。在一定程度上这对于打包也是一样的，很多的浏览器已经内置了对于模块的支持，所以打包更多的被视为一种优化的步骤而不是一种必要的步骤。这种情况越来越多了，所以TS如何跟上呢？

如果我们回顾2012年TS第一次宣布，那时候JS世界有极大的不同。一些浏览器经常发布，但不是所有的。这是不确定的，我们不知道还要忍受老版本的IE浏览器多久，这也导致了一些打包器和编译器得到了应用。TS能够真的繁荣是在当增加一个构建步骤给JS是一个既定事实的时期 - 毕竟，不管怎样，如果你想编译你的JS，为什么不去掉类型呢。如果上面提高的这些趋势继续的话，编译时去掉类型信息可能是在撰写TS和运行TS是唯一的步骤，我不想成为阻碍优秀开发者体验的人。

在某种程度上，我们的JS在这里支持缩小差距，你可能也已经看到了如果你使用类似VS的编辑器或者VS Code。今天，如果你创建一个.js文件在你的编辑器里，而且用JSDoc 注解的方式开始增加类型信息。

  1. /**
  2.  * @param a {number}
  3.  * @param b {number}
  4.  */
  5. function add(a, b) {
  6.     return a + b;
  7. }

因为这只是一些注解信息，他们一点也没有改变你代码的运行方式，他们仅仅是文档的形式，但是TS用他们给你更好的JS编写体验，通过代码完成，重构和其他的一些特性。你甚至可以 add type-checking 通过添加 // @ts-check 在你文件的顶部，或者运行这些文件通过JS编译器 checkJs。这些体验使得难以置信的方便获得一些TS的体验，而不需要构建步骤，你可以把他们用于小脚本，基础网页，Node.js的服务端代码，以及其他。

但是，我们注意到这有一点啰嗦，我们喜爱写JS的内循环是多么的轻量，但是我们却丢失了TS写编写类型时是多么的方便。

所以，如果我们想二者兼有呢？

如果我们有类似TS语法，可以完全被忽略，有点像注解，在JS中。

  1. function add(a: number, b: number) {
  2.     return a + b;
  3. }

我们团队相信这里有一些潜力，这个月我们希望bring it forward in a proposal 给TC39，ECMAScript标准委员会。

它是怎么工作的？

当我们被问到 ‘什么时候JS能有类型’，我们可能犹豫作答。从历史角度讲，问题是如果你问开发者，他们脑子里在想什么对于JS有类型这件事，你可能得到很多不同的答案。一些人觉得类型可以被完全的忽略，而有一些人觉得他们应该有一些意义 - 可能是他们应该加强运行时的校验，或者他们应该是内省的，或者他们应该扮演对于引擎优化的提示，或者更多！但是在过去的几年，我们发现人们越来越倾向于一种设计，与TS发展方向一致的设计 - 类型可以完全被忽略和在运行时删除语法。这种趋势，伴随着TS的广泛使用，让我们感到更加的自信，在我们核心team之外的一些JS和TS开发者再一次的呼吁我们关于这个提议 - ‘types as comments’（类型即注解）

这个提议的核心The idea of this proposal是JS能够开发一套JS类型的语法并且引擎能够完全的忽略，但是像TS、Flow或者其他的一些工具也可以使用。这使得我们可以保留一些我们所喜爱的关于TS的 - 它的类型检查和编辑体验，同时在开发工程中去掉对构建步骤的需要。

所以，当面临撰写和运行代码时，一个开发者的内循环开起来有一点不一样。
image.png
于此同时，撰写代码和类型检查会保持一致。一个开发者能够得到理解的代码类型检查反馈在支持TS的编辑器里，在命令行里运行TS，和TS作为CI任务的一部分。最大的不同是因为我们不再需要构建步骤，会极大的降低对于JS入门的障碍，来体验类型的威力和优秀的工具。
image.png为了让这一切发生，JS需要最想程度上添加一些特性例如变量和函数的类型注解，可选修饰符(?)对于参数和类成员，类型声明(interface和type别名)，类型断言操作符(as和！)，所有的这些都不会影响目前周围代码的运行。

一些访问性修饰符(public, private 和protected)也会在范围之内，然而,enums,namespaces,和参数属性可能会在这次提议之外，因为他们有可观察的运行时行为。这些特性可能作为单独的ECMAScript特性被提议基于反馈，所以我们当前的目标是支持TS中大部分的特性，而且我们相信这对于TS是一个有价值的添加。

通过这样的开拓，我们为类型检查器留出了空间，以需要新的语法的方式进行创新。这意味着引擎可以在有类型的情况下很好的运行，但是我们相信类型检查可能或者应该是规范的相比于运行时更严格的限制。联合起来看，这使得类型语法可以跨不同的类型检查自定义，或者被完全的删除如有的开发者不喜欢TS或者其他的一些类型检查。

它不是什么？

这也值得提一下，这个提议不是什么。
我们团队不是提议把TS类型检查放在每一个浏览器运行环境和JS运行时里 - 不是我们正在提议任何新的类型将会添加到浏览器里。我们认为这样做会对TS和JS的开发和引发问题，由于一系列的问题，例如运行时的性能，已有TS代码的兼容问题，停止类型检查领域创新的风险。

相反，我们仅仅是提议一些与TS兼容的语法和受TS的激发，可以被用于任何的类型检查，但是会被JS引擎忽略。我们相信这个方式是对所有人的承诺，会继续认可TS，Flow和其他的工具继续创新。

接下来？

考虑到这些，我们计划演示这个提议为 Stage 1在即将到来的2022年3月举行的TC39会议。我们将在这项提案的共同倡导者的支持和指导下这样做，

达到Stage 1意味着标准委员会相信为ECMAScript增加类型检查是值得考虑的。但也不是一定确定的事情，仍然有很多有价值的视角在委员会内部，我们也期望一些怀疑。一个像这样的提议一定会受到一些反馈和准确的审查。可以包括一些设计的改变在这个过程中，可能花费数年才能产出结果。

如果我们完成这件事，我们有机会做出最有影响力的改进之一在JS世界。我们是很乐意做成这件事的，希望你也一样。

如果你有兴趣了解更多关于标准和当前的方向，head on over to the proposal repository。我们期待你的想法。