1、esbuild 是使用go语言编写的一个前端构建工具
相对于nodeJs的构建工具如webpack。go语言是纯机器码,没有js的解释过程;go新开了一个进程多线程并行,而js是单线程串行化的,所以从开发语言层面来说就更快。当nodejs还在解析打包程序的js的时候,go已经在解析要构建的js了。
2、esbuild内置了部分的loader直接使用go语言编写,可以直接使用
相对于nodeJs的构建工具中相同功能的loader相比也更快。不同于webpack中loader都要配置添加。比如内置了对.js、.jsx、.ts、.tsx 、.css、.module.css 等的支持,其他文件类型则需要添加社区的loader或者手写插件进行处理,比如:less、sass、img、字体图标库等。
esbuild的生态还不完善,很多插件其实只是包装了开源的loader框架,本质上还是用的js实现的,而且很多社区提供的插件都存在各种问题,需要自己实现插件,比如对css进行浏览器兼容添加浏览器前缀等问题
3、esbuild的代码分割很鸡肋
代码分割可以减小了初始加载时的文件体积,加速页面加载时间;也能提高缓存利用率,节省带宽成本;多个小块的代码可以并行下载,提高整体加载效率。而esbuild的代码分割,只支持esm 格式,对浏览器版本有限制;能对动态 import 的内容或多入口同时用到的代码进行分割。无法做到像webpack一样将使用到的某个库单独打包出去。
4、esbuild不支持HMR,需要借助插件实现。
5、esbuild目前的应用
主要因为esbuild在代码分割、css处理、不支持HMR、没有提供AST能力(不能转换成兼容低版本浏览器代码)等问题,虽然它很快,但它不适合直接用于生产环境,而更适合作为一种偏底层的模块打包工具,需要在它的基础上二次封装。在其他的构建工具中,只是将esbuild应用于开发环境,从而有更快的开发体验,比如在vite中 ,开发环境下使用esbuild快速构建,而构建部署版本时则使用的是rollup;在umi/mfsu中,开发环境下使用esbuild-loader替代label,而构建部署版本时则还是使用的babel。
总的来说,esbuild具有极快的构建速度、可扩展性、支持多种格式、不需要设置各种 loader,配置简单等。但还有很多不足:
- 社区生态很弱,跟 Webpack 和 Vite 完全不在一个量级
- 插件之间兼容性问题很严重
- 代码分割能力太弱,只能基于入口进行分割
- 对目标浏览器版本有一定要求
- 不支持 HMR
- 为了保持结构的一致性,没有提供转化的 AST 的 API
- 由于工具和插件还是采用 JavaScript 编写,存在解析速度相对较慢的可能性
- 对于复杂场景,配置还是像 Webpack 一样复杂
- 可以在简单项目或类库开发中使用
总之,esbuild 不是像 Webpack 是一个大一统项目,提供完善的插件机制,而是在极度精简之后的打包工具,快才是它的追求目标。
文章内容只做学习记录,内容转自别的大佬博客,主要参考:文章来源:https://www.toymoban.com/news/detail-857525.html
Esbuild深度调研:吹了三年,能上生产了吗?文章来源地址https://www.toymoban.com/news/detail-857525.html
到了这里,关于esbuild 极速的JavaScript构建打包工具的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!