微软的 ES 类型语法提案对 JavaScript 意味着什么

如果今年早些时候微软和其他开发人员提交的提案成为 ECMAScript 标准的一部分，JavaScript 很快就会拥有自己的类型语法。该计划计划为 JavaScript 语言添加“类型作为注释”支持，让开发人员使用类型信息注释代码，其他生态系统组件将使用这些信息。

语法

建议的语法如下所示：

function sayAge(name: string, age: number) {

console.log(`${name} is ${age} years old.`);

sayAge("JavaScript", 26);

任何以前使用过TypeScript的人都会熟悉它， TypeScript是 Microsoft 的 JavaScript 的类型化超集。TypeScript 已在整个行业中得到广泛采用；这个新提案旨在为更广泛的 JavaScript 世界带来一些好处。

什么不是提案？

如果它获得批准，该提案将允许您使用上面显示的类型注释编写完全有效的 JavaScript。它将被尊重 ES 标准的 JavaScript 运行时所接受，例如 Web 浏览器、Node.js 和 Deno。

不过，该提案实际上并未扩展 JavaScript 语言。您的类型注释将完全是：对 JavaScript 编译器或代码运行时没有影响的惰性元数据。如下函数调用将在运行时工作：

function sayAge(name: string, age: number) {

console.log(`${name} is ${age} years old.`);

// "age" is a string when it should be a number, but this is still allowed

sayAge("JavaScript", "twenty");

这个想法是提供一种官方支持但被引擎完全忽略的新类型语法。实现的唯一变化涉及识别和剥离类型注释，无论它们在哪里使用。

该提案将寻求建立对参数、变量和类属性类型的注释的支持。它还会考虑添加interface关键字、断言运算符（如!and as）和?修饰符以将类型标记为可选。目的是让所有这些元素镜像 TypeScript；与任何第 0 阶段提案一样，最终结果可能会有所不同。

重点是什么？

如果类型注释不会改变您的程序，那么显而易见的问题是它们是否值得拥有。该提案认为“是”，因为该语法能够缩短迭代时间并减轻现代 JavaScript 工具链的负担。

编写类型安全的代码目前需要您使用 TypeScript，这是一种不同的语言风格，会为您的项目添加依赖项并需要手动编译步骤。然后php源代码，在生成最终的 JavaScript 以供分发之前，该代码可能会通过其他工具，例如模块捆绑器和转译器。它增加了一个具有多个移动部件的复杂工具链。

尽管 JavaScript 本质上是一种松散类型的语言，但强类型的好处现在已被社区广泛认可。从围绕TypeScript 项目的势头可以看出这一点。静态类型也是2021 年 JS调查的“缺失特征”问题中的明显领先者。

向 JavaScript 本身添加类型语法可以让您获得 TypeScript 的一些好处，而无需编译代码。这简化了项目的设置和维护，同时改进了 JavaScript 以更好地与现代开发实践保持一致。

在过去几年中，越来越多的代码开始迁移回“纯 JavaScript”方法。旧版浏览器的衰落使得转译的必要性比以前少了——大多数现代实现都完全支持类、箭头函数、块范围变量和async/等特性await。JavaScript 甚至有一个成熟的模块系统，可以跨引擎工作，包括在浏览器中。

仅在几年前，需要一个冗长的工具链才能将这些功能写入您的代码，并且确信它可以在用户的设备上运行。如今，开发人员可以放心地将这些构建过程搁置一旁，返回到使用

类型是 JavaScript 生态系统中为数不多的未被语言本身容纳的领域之一。爱他们或恨他们，不可否认，类型已成为许多团队和项目的 JavaScript 开发不可或缺的一部分。语法提案正式承认了这一事实。它试图在不破坏现有代码或执行影响性能的运行时类型检查的情况下为 JavaScript 带来一定程度的类型支持。

类型实际上应该做什么？

“类型”的角色因语言而异。共同点在于类型能够表达特定变量将持有的数据类型。然后在该基础上分层添加其他含义、功能和行为。

在 C# 和 Java 等静态类型编译语言中，类型是在编译时强制执行的。当代码中存在类型不兼容时，编译程序是不可能的。在具有可选强类型的解释型语言（其中 PHP 就是一个例子）中，类型是在运行时强制执行的——当值的类型与使用它的上下文不兼容时，程序会抛出错误。

JavaScript 社区中的一个活跃辩论是任何内置类型系统的职权范围应该扩展多远。该提案将其角色限制为最基本的元素，即值的预期类型的简单文档。这与 TypeScript 作为一种在运行时被忽略的可擦除类型语法的位置非常吻合。

该模型的目的是为开发人员在编写代码时提供有关潜在错误的即时反馈。在兼容的 IDE 中编写常规 JavaScript 时，您可以获得有关类型问题的信息。如果您愿意，您还可以使用 TypeScript、静态分析器或捆绑器等支持工具来按需审核您的源代码。当存在类型问题时，这可能会阻止 CI 管道中的部署。

目前的感觉是，这些功能足以使 JavaScript 与最常见的开发人员需求保持一致。JavaScript 生态系统中通常不需要其他语言中的功能，例如内省和反射，部分原因是开发人员已经习惯了 TypeScript 的擦除方法。

现有的替代方案：Docblocks

值得注意的是，类似于提议的擦除注释语法的东西已经存在：熟悉的 JSDoc 标签通常用于向纯 JavaScript 代码添加类型细节：

* @param name {string}

* @param age {number}

function sayAge(name, age) {

console.log(`${name} is ${age} years old.`);

各种流行工具都支持 JSDoc 注释。但是，它们不是语言的标准化部分，它们要求您将代码操作的细节（其预期类型）与包含文档块其余部分的以人为中心的文档混合。

JSDoc 的语法也很冗长。除了必需的标签名称外，它通常需要重复代码中已经存在的元素，例如上面示例中的参数名称。如果你修改了函数签名中的参数，你必须记住也要更改 JSDoc 标签。

新的语法提议可能在功能上等同于 docblocks，但它提供了更加简化的体验。类型作为源代码的一部分位于其目标旁边，而不是在您需要单独创作和维护的文档块中。

下一步是什么？

微软的 TypeScript 团队和包括 Bloomberg、Igwalia 在内的合著者以及几位独立贡献者在 2022 年 3 月的 TC39 全体会议上提交了 Stage 0 提案。该提案已进入第 1 阶段。不过，接受仍有一段路要走，引擎内部的实施可能 要“数年”才能到达。

该提案的首要目标是平衡 JavaScript 的无类型代码的长尾与当前对更静态类型的开发体验的需求。使用擦除的完全可选语法保证了向后兼容性，但增加了它在鼓励采用和巩固生态系统方面无效的前景。随着提案在标准轨道上的进展，围绕这一问题的辩论似乎将随着新的观点和观点而增长。

（编辑：武汉站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!