明天给大家推荐一篇社区作者Kasong的文章。 在这篇文章中，他表达了关于原生JS支持类型注解的一些想法。 来看看他是怎么说的吧~
你好，我是卡森。
在阿姆斯特丹举行的 2022JSConf 会议上，tc39（ES 标准委员会）成员 Gil Tayar 介绍了一项仍处于第一阶段的提案——TypeAnnotations，旨在让原生 JS 支持类型注释。
会议链接：
也就是说javascript是解释，如果动议通过，很多.ts文件只有将后缀改为.js后才能直接在浏览器中运行。
一个 tc39 提案一般会经历 5 个阶段：
所以TypeAnnotations目前还在考虑中。
不过，该动议发起人吉尔·塔亚尔对该动议的通过非常有信心。 本文我们就来谈谈议案的相关内容。
为什么需要本机类型注释？
根据stateofJS 20年和21年的统计，静态类型是JS中最缺乏的功能。
统计链接：
·
同时，在 Github 报告中，TS 被列为第四大最常用语言
举报链接：
因此，对于后端工程师来说，类型注解的需求量很大。
那么，既然 TS 已经有了，为什么还需要原生 JS 支持类型注解呢？ ,
一般来说，开发者编译的源代码与线上生产环境的代码之间需要进行代码编译。 ,
代码编译主要包括两个步骤：
降级编译（包括中间句型到低级句型的转换、中间方法的polyfill）
代码翻译（例如缩小、混淆、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规范的关系类似于右图：
一方面，TypeAnnotations提案借鉴了TS的很多特征，这就是图中相交的部分。
可以去语法约定查看规范当前定义的类型
#语法约定
另一方面，TS的迭代速度非常快，新特征的输出也非常快。 TypeAnnotations作为JS语言的一部分，在迭代上会比较保守，所以TypeAnnotations中不支持TS中的一些特性。
据悉，TS 中的某些结构（例如 Enums、Namespaces）具有运行时语义，而 TypeAnnotations 将不支持它们。
这是 TS 中存在但 TypeAnnotations 中不存在的部分。
最后javascript是解释，TypeAnnotations 的设计并不是为了与 TS 强绑定，而只是提供一组类型规范。 开发者编译代码时的类型检测仍然是通过各种类型检测器（如TS、Flow）来实现。
因此，TypeAnnotations 还有一些特性是目前 TS 未定义的，这也是为了规范更广泛的适用性考虑，即图中 TypeAnnotations 存在而 TS 不存在的部分。
这部分功能需要后期由 TS 来实现，这也是 TypeAnnotations 需要与 TS 团队合作的原因。
对开发者意味着什么
如果TypeAnnotations最终出现在ES20xx版本中，那么当时开发者编译代码的步骤是：
选择一个合适的类型检测器（比如TS），这个类型检测器需要完全符合TypeAnnotations规范（而不是它自己的规范，比如TS规范）
