2022 年，Babel vs TypeScript，谁更适合代码编译【补充参考文献】 - 哈喽比特

450次阅读 | 发布于2年以前

在现代 Web 应用中，为了让代码能在生产环境高性能的运营，源代码往往需要被编译打包，进行死码删除，代码转换等处理。

Babel 和 Typescript 是目前最常用的两个编译器，本文主要讨论两者的区别，帮助你为项目选择最佳工具。

介绍

Babel

Babel 是一个 JS 编译器，能将现代 ES6+ 语法和特性转换为向后兼容语法，以便能够运行在当前和旧版本的浏览器或其他环境中。拥有语法转换，Polyfill，源码转换等能力，

TypeScript

TS 是目前最常用的编程语言之一，是加了类型系统的 JS，能够帮助在开发时规避一些错误。

TS 有自己的编译器，可将 .ts 文件转换为 .js 文件，然后运行在浏览器、Node.js 等任何能运行 JS 的环境中。

两者对比

虽然同为编译器，但也有一些区别。

Babel 无法做到类型检查

TS 在编译时可以对代码进行类型检查，而 Babel 不支持类型检查。

可以使用 tsc -- noEmit 单独进行 TS 类型检查

TS 无法自动 polyfill

Babel 和 TS 两者都只是编译器，真正完成 API polyfill 的是 core-js。

core-js 是一套模块化的 JS 标准库，提供了 polyfill 的核心实现。

Babel 的 @babel/polyfill 模块包含了 core-js 和 regenerator-runtime 来模拟完整的 ES2015+ 环境。因此可以说 Babel 自带了 polyfill。

regenerator-runtime 是 generator 以及 async/await 的运行时依赖。

而 TS 只能通过 tsconfig 的 target 控制编译为对应 ECMAScript 版本的语法。比如 const/let 变 var，箭头函数变 function，async+await 变 Promise.then 这些，不会引入内置对象的扩展，比如你要运行的浏览器不支持 Promise，编译后也不会带一个完整的 Promise polyfill，想 polyfill 还是得配合 core-js。

Babel 扩展性更强

Babel 是自定义代码转换的不二之选，而且社区生态丰富，有各种各样的插件可以优化你的代码。

而 TS 只支持自己的 Transformer API，生态远远比不上 Babel 插件，知道的人也比较少，能力也更少。

装饰器（Decorator）差异

随着 TS 和 ES6 里引入了类，装饰器提案 proposal-decorators[1] 诞生了，是我们最熟悉的老朋友。但是此装饰器非彼装饰器，历时多年来该提案已经走到了第三版，仍然卡在 stage-2。

首先我们需要知道，JS 与 TS 中的装饰器不是一回事，JS 中的装饰器目前依然停留在 stage-2 阶段，并且目前版本的草案与 TS 中的实现差异相当之大（TS 是基于第一版，JS 目前已经第三版了），所以二者最终的装饰器实现必然有非常大的差异。

其次，装饰器不是 TS 所提供的特性（如类型、接口），而是 TS 实现的 ECMAScript 提案（就像类的私有成员一样）。TS 实际上只会对 stage-3 以上的语言特性提供支持，但因为一些原因，当 TS 引入装饰器时，JS 中的装饰器依然处于 stage-1 阶段。TS 的装饰器其实是 JS 装饰器提案的第一版。

Babel 编译装饰器需要使用 @babel/plugin-proposal-decorators 插件，通过 version 字段分别支持三版提案：

"2021-12"
"2018-09"（默认）
"legacy"

Babel 默认按第二版进行编译，如果要与 TS 编译行为一致（也就是第一版），需要传入 "version": "legacy"。

Babel 支持更多语言特性

从上面装饰器的例子还可以看出，TS 只会对 stage-3 以上的语言特性提供支持，不支持还在草案阶段的特性。

而 Babel 的 preset-env 支持所有标准特性，还能通过各种 @babel/plugin-proposal-<语言特性> 插件来支持更多还未进入标准的特性。

两者编译速度相当

在性能上，两者差别不大。这里大家可能会有疑问：“Babel 少了类型检查的步骤，编译速度应该会比 TS 快才对啊”。

根据 swc-node[2] 文档的 benchmark 我们可以看到，在关闭类型检查的情况下，TS 的编译速度是比 Babel 快的。

esbuild x 510 ops/sec ±1.28% (88 runs sampled)
@swc-node/core x 438 ops/sec ±1.00% (88 runs sampled)
typescript x 28.83 ops/sec ±10.20% (52 runs sampled)
babel x 24.21 ops/sec ±10.66% (46 runs sampled)
Transform rxjs/AjaxObservable.ts benchmark bench suite: Fastest is esbuild

而且还可以借助第三方插件 fork-ts-checker-webpack-plugin[3] 来提速类型检查过程（放到单独的进程中），所以两者的整体性能其实相差不大。

Babel 产物体积更小

因为 TS 无法自动 polyfill，借助了 core-js 也无法做到按需 polyfill。

而配置 Babel 的 @babel/preset-env 插件：

useBuiltIns: "usage"
添加目标浏览器 targets: <需要兼容的浏览器>

可以根据编译目标和项目的 API 使用情况来精准添加 polyfill，这会大大降低包的体积。

使用 useBuiltIns: "usage" 会在全局添加 polyfill，这会污染全局环境。可以使用 @babel/plugin-transform-runtime 插件为库的代码提供一个沙盒环境，把 polyfill 变成模块化的引入，代码重用的同时避免全局污染。

总结

综上，两者都有各自的编译处理方式，整体看下来，Babel 唯一的缺点就是没有类型检查，但可以使用 tsc --noEmit 单独检查类型。

因此，如果项目中：

已有 Babel 和 TypeScript，最好使用 Babel 编译代码，使用 TS 进行类型检查和生成 .d.ts 文件。

TS 文档[4]中也更推荐这种方式，但如果构建输出文件和源码差别不大的话，可直接使用 TS 编译。

只有 TypeScript，可以保持现状，将来如果需要 Babel 提供的能力，可以将 TS 编译输出的 JS 再使用 Babel 编译，或者直接使用 Babel 编译 TS 文件。
只有 Babel，推荐使用 TypeScript 对项目进行渐进式改造，保证项目前端质量。

参考资料

[1]proposal-decorators: https://github.com/tc39/proposal-decorators

[2]swc-node: https://github.com/Brooooooklyn/swc-node#benchmark

[3]fork-ts-checker-webpack-plugin: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin

[4]TS 文档: https://www.typescriptlang.org/docs/handbook/babel-with-typescript.html