乐趣区

关于javascript:原生JS以后也支持类型注解啦

jiezi

大家好，我卡颂。

在布达佩斯 2022 JSConf 会议上，tc39（ES 规范委员会）成员 Gil Tayar 介绍了一份以后仍处于 stage 1 阶段的提案 —— Type Annotations，意在让原生 JS 反对类型注解。

换句话说，如果提案通过，很多 .ts 文件将后缀改为 .js 后就能间接在浏览器中运行。

一份 tc39 提案通常会经验 5 个阶段：

  • stage 0：被提出
  • stage 1：承受审议
  • stage 2：标准根本实现
  • stage 3：期待被实现
  • stage 4：纳入语言规范中

所以 Type Annotations 以后仍处于 承受审议 的状态。

然而提案发起者 Gil Tayar 对这份提案的通过很有信念，本文咱们来聊聊这份提案的相干内容。

欢送退出人类高质量前端框架群，带飞

为什么须要原生类型注解？

依据 20 年、21 年 state of JS 的统计，动态类型 高票当选JS 中以后最欠缺的性能。

同时，在 Github 报告中，TS被列为 第四大最罕用的语言

所以，对前端工程师来说，类型注解 需要很大。

那么，既然曾经有了 TS，为什么还须要原生JS 反对 类型注解 呢？

通常来说，从 开发者编写的源代码 到线上生产环境代码 间须要通过 代码编译。

代码编译 次要包含两个步骤：

  1. 降级编译（包含高级语法转换为低级语法，高级办法的polyfill）
  2. 代码转译（比方压缩、混同、tree-shaking、类型擦除）

所谓 类型擦除 ，是指擦除代码中的 类型注解 ，让其变成合乎原生JS 标准的代码，比方：

// 擦除前
function add(a: number, b: number): number {return a + b;}
// 擦除后
function add(a, b) {return a + b;}

随着工夫的推移，各支流浏览器兼容性越来越好，步骤 1 在可预感的将来重要性会逐步升高。

对于 TS 开发者，从 源代码 到线上生产环境代码 间可能只须要 类型擦除。

如果原生 JS 反对 类型注解 ，就能省去 类型擦除 对应的编译流程，让代码更容易在宿主环境执行。

和 TS 的关系

这份提案的目标，并不是重整旗鼓，独立实现一套原生 JS 的类型注解。而是与 TS 团队 单干，提出一套适合的标准。

新的标准与 TS 标准 的关系相似下图：

一方面，Type Annotations提案从 TS 中借鉴了很多个性，这就是图中相交的局部。

你能够到 grammar-conventions 看到标准以后定义的类型

另一方面，TS迭代速度很快，新的个性产出很快。而 Type Annotations 作为 JS 语言的一部分，迭代会更加激进，所以 TS 中一些个性在 Type Annotations 中并不反对。

此外，TS中一些构造（比方 Enums、Namespaces）存在运行时的语义，Type Annotations 也不会反对。

这些就是 TS 中存在，而 Type Annotations 中不存在的局部。

最初，Type Annotations设计的初衷并不是与 TS 强绑定，而仅仅是提供一套类型标准，开发者编写代码时的 类型查看 还是由各种类型查看器（比方TS、Flow）实现。

所以，Type Annotations还有一部分个性是 TS 以后未定义的，这也是为了标准更宽泛的适用性思考的，也就是图中 Type Annotations 存在，而 TS 不存在的局部。

这部分个性须要 TS 后续实现，这也是为什么 Type Annotations 要与 TS 团队单干的一大起因。

对开发者意味着什么

如果 Type Annotations 最终呈现在 ES20xx 版中，届时开发者编写代码的步骤是：

  1. 抉择适合的类型查看器（比方 TS），这个类型查看器须要齐全遵循Type Annotations 标准（而不是本人的标准，比方 TS 标准）
  2. 编写带类型申明的原生 JS 代码
  3. 类型查看器会查看类型谬误，并给予报错或提醒

对于如下原生 JS 代码，如果开发者传入了谬误的类型，JS会报错么？

function add(a: number, b: number): number {return a + b;}

// 谬误的类型传参
add('KaSong', 123);

答案是：不会。

Type Annotations仅仅是一套标准，该标准由各种类型查看器执行。

JS的宿主环境（比方浏览器）在执行 带类型申明的 JS 代码 时，会疏忽类型申明。

总结

有同学可能会问：就为了缩小编译时 类型擦除 这一步，就提出原生类型标准，有必要么？

甚至当 Type Annotations 落地后，开发者上线前在进行代码压缩时，类型擦除 也会作为 代码压缩 的职责之一。

从这个角度看，甚至没有缩小编译时的工作量。

所以提出原生的类型标准，有必要么？

前端的倒退理论是一个 致力去编译时流程 的过程。

比方，编译时代码须要降级，须要 polyfill？随着IE11 进行服务，支流浏览器纷纷跟进规范落地，降级与 polyfill 的需要逐步变少。

再比方，代码须要打包？随着 ESM 标准落地，在以后，至多在开发环境中代码曾经不须要打包（应用Vite）。

Type Annotations的呈现，就是遵循 致力去编译时流程 这一趋势的产物。

从这个角度看，还是很有必要的。

退出移动版