微软、伊加利亚和彭博 他们几天前宣布 已经主动加入了语法 对于规范中的显式类型定义 JavaScript，类似于 TypeScript 语言中使用的语法。
目前，提议包含在 ECMAScript 标准中的原型更改已提交进行初步讨论（第 0 阶段）。
今天，我们很高兴地宣布我们对新的 Stage 0 提案的支持和合作，为 JavaScript 带来可选和可擦除的类型语法。 因为这种新语法不会改变周围代码的执行方式，所以它们实际上就像注释一样。 我们认为这有可能使 TypeScript 更容易、更快地用于各种规模的开发。 我们想谈谈我们为什么要追求这个，以及这个提案在高层次上是如何运作的。
提到在 t拥有明确的类型信息将防止开发过程中出现许多错误， 它将提供使用额外优化技术的机会，简化调试，并使代码更具可读性，更易于第三方开发人员修改和维护。
除此之外 建议将类型支持实现为可选功能： 不支持类型检查的 JavaScript 引擎和运行时将忽略带有类型信息的注释并像以前一样处理代码，将类型数据视为注释。 但是类型检查工具将能够根据可用信息检测与错误使用类型相关的错误。
背景
我们的团队在 JavaScript 世界中看到的最近趋势是对更快迭代时间和减少构建步骤的需求。 换句话说，“让它更快更简单”。在某种程度上，这已经在发生了。 由于常青浏览器的成功，开发人员通常可以避免编译较新版本的 JavaScript 以在较旧的运行时上运行。 在某种程度上，捆绑也是如此：大多数浏览器都内置了对使用模块的支持，因此捆绑更多地被视为一种优化步骤，而不是必需品。 这种情况越来越多，那么 TypeScript 是如何坚持的呢？
与此同时， 不同于指定的类型信息 通过指定为注释的 JSDoc 注释， 直接规范 直接在变量定义结构中的类型 它将使代码更直观、更易于理解且更易于编辑.
例如，支持 TypeScript 的 IDE 将能够立即突出显示编写的 JavaScript 代码中的错误，而无需额外的转换。 此外，内置的类型支持将使运行以脚本化 JavaScript 方言（如 TypeScript 和 Flow）编写的程序成为可能，而无需从一种语言转换为另一种语言。
在这些类型中，建议添加“string”、“number”和“boolean”，可以在定义变量、函数参数、对象元素、类字段、类型化数组（“number[]”）时使用。 还建议为混合类型（“字符串|数字”）和泛型提供支持。
鉴于所有这些，我们计划在 1 年 2022 月的 TC39 全体会议上提交第 XNUMX 阶段的提案。 我们将在该提案的共同拥护者、彭博的 Rob Palmer 和 Igalia 的 Romulo Cintra 的支持和指导下这样做。
达到第 1 阶段意味着标准委员会认为 ECMAScript 的兼容类型语法值得考虑。 这不是一个确定的事情：委员会中有许多有价值的观点，我们预计会有一定程度的怀疑。 像这样的提案会得到很多评论和适当的审查。 在此过程中可能涉及大量设计更改，并且可能需要数年才能获得结果。
在下次会议上 三月的 TC39委员会，计划进入第一阶段 在 ECMA 专家社区的参与下审议该提案。
最后 如果您有兴趣了解更多信息， 您可以在中查看详细信息 以下链接。