原生JS以后也支持类型注解的意义是什么

今天小编给大家分享一下原生js以后也支持类型注解的意义是什么的相关知识点，内容详细，逻辑清晰，相信大部分人都还太了解这方面的知识，所以分享这篇文章给大家参考一下，希望大家阅读完这篇文章后有所收获，下面我们一起来了解一下吧。

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

根据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代码时，会忽略类型声明。

以上就是“原生JS以后也支持类型注解的意义是什么”这篇文章的所有内容，感谢各位的阅读！相信大家阅读完这篇文章都有很大的收获，小编每天都会为大家更新不同的知识，如果还想学习更多的知识，请关注编程网精选频道。