前端工程化历程与 Turbopack 概述

1. 前端工程化历程与 Turbopack概述范文杰来自字节跳动-飞书 aPaaS

2.

3. 关于我 • • 前端工程化爱好者目前就职于字节跳动-飞书 aPaaS 团队，Base 深圳(有 HC) • • 掘金小册《Webpack5 应用实践与核心原理》作者公众号「tecvan」作者 • 来自广东潮汕地区，普通话不好，见谅

4. 问题 • 为什么会出现这么多构建工具？ • 这些工具背后的设计思路是怎样的？带来了哪些变化？ • 我们现在还面临什么问题？未来可能怎么发展？

5. 目录 01 回顾历史 02 聊聊现在 03 可能的未来

6. 过去

7. 远古时代 • 页面需求比较简单 • 但工程化程度极低，运行时与开发时几乎完全等价，需要以 ES3、CSS2、HTML3 方式编写页面，开发效率极低 • 需要花许多时间考虑代码兼容性问题 • 需要花许多时间调整多媒体资源(甚至，当时大多数人没有意识到 web 性能问题) • 前后端职能并未严格分离 • 零零星星，出现过一些解决单点问题的工具，但彼此割裂不成体系 • 例如：YUICompressor JS 无法脱离浏览器运行，前后端职能耦合

8. 2009 年，NodeJS 发布前端进入一个全新的时代 NodeJS 的出现，使得 JS 能够脱离浏览器运行，也催生了许多效率工具。

9. 问题：怎么把它们整合在一起？

10. Gulp – 任务执行器用户负责定义一系列构建任务；Gulp 负责调度(任务依赖管理、并串行模型)执行思路：专注做好构建任务调度、执行，不关心构建细节，与具体构建逻辑解耦，能够卷入许多现成工具；变化：前端终于有了 JS 闭环的一体化构建工具问题： • 任务间互不相通，重复度高，性能较差； • 不同资源依然走各自的处理逻辑，没有形成统一的心智模型

11. 问题：有没有更高效的整合方式？

12. 现在

13. Webpack – 配置驱动的资源打包器工作时会通过各种 Loader 读入原始文件，解析为 AST，分析依赖，进一步找到更多依赖模块，迭代直至找到所有资源，最后再将资源一并打包。 • 基于 Loader 兼容任意资源； • 暴露 AST 级别的 API，方便扩展； • 广度优先，计算出模块依赖拓扑关系； • 最后整合打包成适合在浏览器运行的产物包。

14. Webpack – 配置驱动的资源打包器思路：以一致的方法论处理不同类型资源，检索资源依赖并最终合并打包(Bundle) • 定义主流程：遍历、转译 AST、递归分析资源依赖，打包； • 主流程之外，开放一些改变运行逻辑的口子(Hook & Loader)，第三方可借助这些口子调整构建逻辑，扩展资源处理逻辑等(所有资源都是一等公民)； • 内置 devServer、hmr、sourcemap 等工具，开箱即用；优势： • 先发优势 • 扩展性强，绝大多数工程化工具，都能通过插件或 • 问题： • 重！性能为人诟病(Webpack5 引入持久缓存、Lazy Compilation 后，有所缓解) loader 形式接入 webpack 体系 • 产物质量不佳(体积过大) 使用最广泛，生态最完善，几乎能满足所有前端场景 • 架构/功能逻辑复杂，资料匮乏，学习难度较大构建需求 • 大而全，强调兼容性，但也同时实现了许多并未成为规范的特性，导致不够规范

15. 问题：我们真的需要 Bundle 吗？ • 项目越来越复杂，依赖越来越多，构建编译速度越来越慢 • HTTP2、ESM 等新技术已经得到浏览器广泛支持

16. Vite – 功能完备的 devServer • 传统 Bundle 方案在现如今大规模项目场景下，实在慢的发指，动辄几十秒，甚至几十分钟 • Esm 推广的很顺利，很多浏览器原生支持 esm • 基于原生语言的，速度更快的工具(esbuild)已经逐步成熟 • Snowpack 已经证明这条路走的通于是，Vite 预设现代浏览器大多数已经原生支持 ESM 规范，构建工具 —— 特别是开发环境下已经没有太大必要为了低版本兼容把大量的时间花在编译打包上了！

17. Vite – 功能完备的 devServer 思路：不直接做构建功能，但把 devServer 能力与性能做到极致 • 开发环境基于 ESM 实现按需(根据 HTTP 请求，用到的时候才编译)编译(源码 => 适配浏览器的形态)，使用 ESBuild 提升编译速度 • 生产环境依然使用 Rollup 做 Bundle 打包(避免重复造轮子)，构建方式与 webpack 相似，并无本质区别 • 内置功能齐全的 devServer 工具，满足开发需求优势：问题： • 启动速度快的离谱 • 开发模式下网络请求数非常多，可能导致性能问题 • 借助 ESBuild，开发阶段可以做到极快的单模块编译 • 生成模式构建逻辑与 Webpack 并无本质区别 • 文档、开发体验都非常棒 • 封装的很好，但复杂度不会凭空消失，用户迟早还是会接触到底层的 ESBuild 或 Rollup

18. 虽然…但是…，它来了 Turbopack: The Rust-powered successor to Webpack

19. 可能的未来

20. Turbopack – 据说很快！吃瓜： • 《Introducing Turbopack: Rust-based successor to Webpack》 By @Tobias Koppers • 《Is Turbopack really 10x Faster than Vite?》 By @yyx • 《Turbopack Performance Benchmarks》 By @Tobias Koppers

21. 为什么能做到这么快？

22. Turbo Engine 1. 基于 Tokio 的调度系统 2. 函数级缓存 Turbo Engine

23. Turbopack 1. Turbopack 延迟执行(turbopack-dev-server)的 ModuleGraph 收集算法； • AssetReference: 对标到 Dependency • Asset: 对标到 Module & Chunk Turbo Engine 2. 基于 Rust 重写 js、css 等资源解析、转译逻辑(SWC)；

24. Next Adapter Next Adapter • 基于 Rust 实现 • 负责对接 Next 框架，实现 SSR 等 Turbopack Turbo Engine

25. Turbopack – A successor to Webpack • 函数级的缓存，避免重复执行相同计算； • HTTP 请求级别的延迟计算； • Rust 重写资源处理逻辑(CPU 密集计算)；

26. But

27. 最后，我们来做个对比

28.

29. State of JS 2022

30. NPM Trending • Vite 与 Webpack Stars 接近 • 但，Webpack 下载量依然是绝对的榜首 • Rollup 下载量高居榜二

31. 我对前端工程化的一些思考快了，真的快结束了~~

32. 工程化解决了什么问题？ • 是什么？ • • • • 完整链路：开发、编译(构建)、调试、测试、CI/CD 目标： • 很简单，提效！包括代码开发、调试、测试、部署等方面； • 提效带来了一个意料之内的副作用：能够支撑起复杂应用的开发手段： • 风格：eslint、prettier • 生产 & 开发隔离：babel、TypeScript • 测试：jest • 工作流：webpack、rollup、turbopack • CI/CD: github action 等结果：我们已经具备开发大型应用的能力

33. 我们真的需要这么多工具吗？ • 工具不是结果，而是过程，是前人不断探索，不断以更优方式解决相似问题所带来的副产品； • 时至今日，我们还面临超大规模项目带来的工程化效率低、依赖管理复杂等问题； • 因此，未来的趋势： • • 必然会出现更多基于原生语言实现的工程化工具 • 性能！我们能够充分用好多核 CPU 算力 • 新语言与 JS 有不错的协作融合，并不需要为此增加太多复杂配置 Webpack 依然是主流工具；但可能没有 Webpack7；Turbopack 会逐渐成长发展起来，长期应该会成为主流； • 项目越来越大，构建越来越慢，提升构建速度只能解决一部分问题；更长久的未来可能会大范围普及 Monorepo(turbopack、nx、rush 等)，切分项目复杂度

34. 扫码回复「D2」获取第十七届 D2 演讲 PDF 材料后续也将推送 D2 会后技术文章，敬请关注！！

35. 感谢大家观看