大家好，我是Kason。在布达佩斯的2022JSConf大会上，tc39（ES标准委员会）的成员GilTayar提出了一个目前还处于stage1的提案——TypeAnnotations，旨在让原生JS支持类型注解。也就是说，如果提案通过，很多.ts文件在将后缀改为.js后，可以直接在浏览器中运行。一个tc39提案通常要经过5个阶段：stage0：提议stage1：接受审核stage2：规范基本完成stage3：等待实施stage4：包含在语言标准中所以TypeAnnotations仍在审核中。不过，提案的发起人吉尔·塔亚尔对提案的通过非常有信心。在本文中，我们将谈谈提案的相关内容。欢迎加入人类优质前端框架群。为什么戴飞需要原生类型注解？根据20和21年JS状态统计，静态类型被评为JS中最缺乏的功能。同时，在Github报告中，TS被列为第四大最常用语言。因此，对于前端工程师来说，类型注解的需求量很大。那么，既然TS已经有了，为什么还需要原生JS来支持类型注解呢？一般来说，开发者编写的源代码与线上生产环境中的代码之间需要进行代码编译。代码编译主要包括两个步骤：降级编译（包括高级语法到低级语法的转换、高级方法的polyfill）代码翻译（如压缩、混淆、tree-shaking、类型擦除）。所谓类型擦除，是指擦除代码中的类型注解，使其成为符合原生JS规范的代码，例如：//擦除前functionadd(a:number,b:number):number{returna+b;}//擦除后functionadd(a,b){returna+b;}随着时间的推移，各大浏览器的兼容性越来越好，第1步的重要性会逐渐降低可以预见的将来。对于TS开发者来说，从源代码到线上生产环境代码可能只需要类型擦除。如果原生JS支持类型注解，则可以省略类型擦除对应的编译过程，让代码更容易在宿主环境中执行。与TS的关系本提案的目的不是从头开始，独立实现一套原生的JS类型注解。相反，与TS团队合作提出一套合适的规范。新规范与TS规范的关系类似于下图：一方面，TypeAnnotationsproposal借鉴了TS的很多特性，也就是图中相交的部分。你可以去grammar-conventions查看规范当前定义的类型。另一方面，TS迭代速度非常快，新特征产生的速度非常快。TypeAnnotations作为JS语言的一部分，在迭代中会比较保守，所以TypeAnnotations不支持TS中的一些特性。此外，TS中的一些结构（如Enums、Namespaces）具有运行时语义，TypeAnnotations将不支持它们。这些是TS中存在但类型注释中不存在的部分。最后，TypeAnnotations设计的初衷并不是为了和TS强绑定，只是提供一套类型规范。开发者编写代码时的类型检查，仍然是通过各种类型检查器（如TS、Flow）来实现的。因此，TypeAnnotations还有一些特性目前TS没有定义，这也是为了规范更广泛的适用性考虑，即图中有TypeAnnotations而TS没有的部分。这部分功能需要后期由TS来实现，这也是TypeAnnotations与TS团队合作的原因之一。对开发者意味着什么如果TypeAnnotations最终出现在ES20xx版本中，那时候开发者编写代码的步骤是：选择一个合适的类型检查器（比如TS），这个类型检查器需要完全遵循TypeAnnotations规范（不是自己的Specifications，比如TSspecifications）写原生JS代码，类型声明类型检查器会检查类型错误，并给出错误或提示对于后面的原生JS代码，如果开发者传入了错误的类型，JS会报错一个错误？functionadd(a:number,b:number):number{returna+b;}//传错类型参数add('KaSong',123);答案是不。类型注释只是一组规范，由各种类型检查器强制执行。JS宿主环境（如浏览器）在执行带有类型声明的JS代码时会忽略类型声明。小结有同学可能会问：难道仅仅为了减少编译时类型擦除的步骤就需要提出native类型规范吗？即使实现了TypeAnnotations之后，当开发人员在上线前压缩代码时，类型擦除也会成为代码压缩的职责之一。从这个角度来看，它甚至没有减少编译时的工作。那么是否有必要提出原生类型规范呢？前端的开发其实就是一个尝试编译的过程。比如代码编译的时候需要降级，需要polyfill？随着IE11的下线，主流浏览器纷纷跟进标准的落地，降级和polyfill的需求逐渐减少。再比如，代码需要打包吗？随着ESM规范的实施，目前至少在开发环境中，代码不需要打包（使用Vite）。TypeAnnotations的出现是跟风尝试编译时间流的产物。从这个角度来说，还是很有必要的。
