大家好，我卡颂。
在布达佩斯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反对类型注解呢？
通常来说，从开发者编写的源代码到线上生产环境代码间须要通过代码编译。
代码编译次要包含两个步骤：
- 降级编译（包含高级语法转换为低级语法，高级办法的
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标准的关系相似下图：
一方面，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版中，届时开发者编写代码的步骤是：
- 抉择适合的类型查看器（比方
TS），这个类型查看器须要齐全遵循Type Annotations标准（而不是本人的标准，比方TS标准） - 编写带类型申明的原生
JS代码 - 类型查看器会查看类型谬误，并给予报错或提醒
对于如下原生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的呈现，就是遵循致力去编译时流程这一趋势的产物。
从这个角度看，还是很有必要的。
发表回复