专栏中的代码均在 http://github.com/sunny-117/esbuild-book
完整版在掘金专栏地址:https://juejin.cn/column/7285233095058718756
esbuild
是一款基于 Go
语言开发的 javascript
构建打包工具,相比传统的构建工具,主打性能优势。同样规模的项目,使用 Esbuild
可以将打包速度提升 10
- 100
倍,这对广大一直饱受 Webpack
缓慢打包速度折磨的开发人员来说,简直就是福音。
采用 Go 语言开发,传统的JS开发的构建工具并不适合资源打包这种 CPU 密集场景下,Go更具性能优势。
go具有多线程运行能力,而JS本质上就是一门单线程语言。由于go的多个线程是可以共享内存的,所以可以将解析、编译和生成的工作并行化。
从一开始就考虑性能,不使用第三方依赖,从始至终是使用的是一致的数据结构,从而避免数据转换无意义的消耗。
在 JS 开发的传统打包工具当中一般会频繁地解析和传递抽象语法树( AST )数据,比如 字符串 -> TS -> JS -> 字符串,然后字符串 -> JS -> 旧的JS -> 字符串,然后字符串 -> JS -> minified JS -> 字符串
,这其中会涉及复杂的编译工具链,比如 webpack -> babel -> terser
,每次接触到新的工具链,都得重新解析 AST,导致大量的内存占用。
esbuild 仅触及整个JavaScript AST 3次:
当 AST 数据在CPU缓存中仍然处于活跃状态时,会最大化AST数据的重用。
虽然esbuild有很多优点,但是缺点也非常的明显,从esbuild的官方文档upcoming roadmap中,就能看出下面的问题:
简单来说,现在希望直接将esbuild放入到生产环境中,还需要一些路走,并不足以支撑一个大型项目的开发需求。有些内容虽然我们可以通过插件去实现,但是并不是开箱即用的功能,对于项目开发的新手来说,并不友好。变相增加了开发成本
无论如何,esbuild
为我们所熟知,还是因为Vite,esbuild
是组成Vite
的两架马车之一。
一个字...快
现在来说,Vite在下面几个地方都依托于esbuild,而未来随着esbuild的完善,应该会做进一步处理
ESM
是JavaScript
提出的官方标准化模块系统,不同于之前的CJS
,AMD
,CMD
等等,ESM
提供了更原生以及更动态的模块加载方案,最重要的就是它是浏览器原生支持的,也就是说我们可以直接在浏览器中去执行import
,动态引入我们需要的模块,而不是把所有模块打包在一起。
Vite 是一个提倡 no-bundle
的构建工具,相比于传统的 Webpack,能做到开发时的模块按需编译,而不用先打包完再加载。
模块代码其实分为两部分,一部分是源代码,也就是业务代码,另一部分是第三方依赖的代码,即node_modules
中的代码。所谓的no-bundle
只是对于源代码而言,对于第三方依赖而言,我们基本不会去改变他,Vite 还是选择 bundle(打包),这个部分,就依赖于esbuild
。
但是关键点是,为什么在开发阶段我们要对第三方依赖进行预构建? 如果不进行预构建会怎么样?
首先 Vite 是基于浏览器原生 ES 模块规范实现的 Dev Server,不论是应用代码,还是第三方依赖的代码,理应符合 ESM 规范才能够正常运行。但是,我们没有办法控制第三方的打包规范。还有相当多的第三方库仍然没有 ES 版本的产物。
此外,ESM还有一个比较重要的问题——请求瀑布流问题。ESM的每个import
都会触发一次新的文件请求,因此在依赖层级深
、涉及模块数量多
的情况下,会触发很多个网络请求,巨大的请求量加上 Chrome 对同一个域名下只能同时支持 6个 HTTP 并发请求的限制,导致页面加载十分缓慢,与 Vite 主导性能优势的初衷背道而驰。
在进行依赖的预构建之后,这种第三方库的代码被打包成了一个文件,这样请求的数量会骤然减少,页面加载也快了许多
完整版在掘金专栏地址:https://juejin.cn/column/7285233095058718756
#你认为工作的意义是什么##晒一晒我的offer##我的求职思考##我的实习求职记录##2022届毕业生现状#