聊聊2021年高效能的前端技术架构

前言

2021 要结束了，不管是从 vue 3 从去年下半年开始走高到今年爆火也好，还是 modern bundle 技术在 2021 掀起新的内卷风潮，各种工具轮子爆发式增长，react 18 高度变革......，当然不止这些，显然 2021 年在一年时间内 fe 圈出现了太多新物质，无数涌现以使无法完全涵盖，但作为收年之作，我更想聊的是一个理想的 FE 技术架构是如何？

在聊之前，我们先定义一下这里的 “架构” 是何含义，首先我们不会讨论大企业里的基建挂钩的架构，因为即使讨论了，对于一般的中小开发者来说也只是叶公好龙，比如 serverless、modernjs、云函数等，这些对于中小开发者来说是很难有人力财力去落地的。

我更希望讨论的是一个 普适 的技术效能体系，人人都可以伸手可得的，人人都可以做到的，能真正为业务赋能的东西才是我真正想聊的（但是这也不意味着 0 成本和 0 上手难度）

正文

下面我们从几个关键的点入手进行介绍。

包管理工具：pnpm

pnpm 这个东西我就不在这里再聊一遍他的历史了，这个东西我们已经探讨了太多次，已经几乎摸索到了目前很好的一个临界点去应用他，并着实享受他惊人的好处。

你可以从这里追溯我们以前对 pnpm 的探索：

《 为什么使用 pnpm 可以光速建立好用的 monorepo（比yarn/lerna效率高）》

《 pnpm monorepo 之多组件实例和 peerDependencies 困境回溯 》

《 pnpm monorepo 的技术选型临界点（Critical adoption） 》

可以肯定的是他高效的性能，严格的隔离机制已经给我们带来了太多 awesome 的好处，这一点上真的无需多言。

新物质产生后往往需要一个漫长的验证和实践、迁移过程。

🥰 所以 2022 年 pnpm 不会取代 npm/yarn

monorepo 支持：pnpm monorepo

早期应该是 lerna + yarn workspace 霸占这一领域，但是 2021 我更推荐 pnpm monorepo，这一点其实在上面选择 pnpm 作为包管理工具的时候，几篇文章内已经详细介绍过了，高可配置、极高的使用效率、严格的依赖区分是我们在业务场景进行投入的根本原因，这里也不再多言。

🥰 所以 2022 年 pnpm monorepo 不会取代 lerna

发包工具：changesets

在包管理和发布上，我更推荐 changesets 这个工具，不光是 pnpm 本仓和很多开源大仓在使用 changesets，而是他清真的工作流思想，高效的批量发包机制，真正的可以帮我们解决一个 monorepo 管理包的各种问题。

关于这点你可以从上文 pnpm 的文章内找到许多对 changesets 的描述，任何事物都将走向自动化，这也是 changesets 告诉我们的真理：大人，手动发包的时代变了。

🥰 所以 2022 年 changesets 不会取代 lerna/手动发包

monorepo 依赖拓扑和构建流：turborepo

只要使用 monorepo ，必然随着业务的体量增加要面临复杂度指数级上升难以管理相互依赖关系的问题，而 turborepo 就可以帮助我们寻求最佳拓扑依赖流，完成依赖构建和项目构建，nextjs 买下 turborepo 给自己使用我想是一个明智而又正确的抉择。

关于 turborepo 的相关内容你可以在这里追溯：

《 使用Turborepo进行复杂拓扑关系的monorepo最优构建 》

🥰 所以 2022 年 turborepo 不会取代 shell/手工脚本

项目开发基础：自定义 webpack5

不管 wp5 也好，其实从 wp4 开始大家都只是在用 vue-cli / cra 这种封装好了的工具，不得不承认的是他们都十分优秀，先人的坑已经被填好，我们使用其开发时可以获得到优质的体验，所以这也是更多的人不去深入 webpack 的原因。

但到了 wp5 时代，性能上和功能上都相对其他工具发生了一个较为明显的 gap ，加上 vite 为主的各种 unbundle、bundleless 的同台竞赛，显然我们停留在 wp4 是有点 “上古” 了，所以我们现在的解法是自定义 webpack5，当然 wp5 相比 wp4 来说配置的坑也更多，配置方法也更复杂，进行一个比较深度的优化是需要比较深厚的功力的。

早期我有幸撰写过一些 webpack5 的内容，你可以从这里追溯：

《 从17个角度入门Webpack5+Typescript（附即开即用模板）》

webpack5 及其生态是一个比较庞大的知识体系，所以即使是从这 17 个角度仍然无法覆盖全面，最多只能修炼到 60% ，从个人角度来说，完美的实践不存在于教程里，而在实际落地的架构里，只有深度的修炼，才能开启此门。

谈到修炼，我更推荐你去阅读、背诵 react-scripts 的源码，vue-cli 的配置，umijs 的思想，相信你都会受益匪浅。（这个时间 cra 5 已经发版，但是其存在太多历史遗留和超级多的新问题，仍然非常难用，但不干扰我们从源码汲取需要的知识）

🥰 所以 2022 年 webpack5 不会取代 webpack4 / vue-cli / cra

业务框架：React17 + Typescript

框架之争可谓是长久以来的话题，如果你是一个深度的 Vue + React 使用者，使用他们都进行过深度的开发，可能会心知肚明两者之间的区别，当第三者提出我应该使用 Vue 也好，还是使用 React 也好，你都能 get 到那个点，所以我这里不会展开聊。

站在我的角度来说 pc 开发使用 React ，手机端开发使用跨端框架（跟随框架技术栈走），其次使用 Vue ，因为 vue 在 mobile 侧独立能力比较成熟。

从另一个角度来说，因为开发者 yyx 是华人的关系，Vue 源码成为了 fe 必须背诵的必修课，我也认同这一点，并且也持续保持源码级的认知和跟进，持续修炼 Vue 底层源码是一个很好的发展方向，因为这很 dssq 。

🥰 所以，2022 年 React 不会取代 Vue

现代化支撑：swc + esbuild

现代化打包技术层出不穷，不管是 unbundle 、bundleless ，还是使用更高效的语言入侵 fe 构建链路，在 2021 年间都进展神速，甚至都出现了人为故意要给 vite sleep 一会儿的插件。

针对 webpack5 系，我们使用 swc + esbuild 加速打包是一个最优解法，当然如果你还需考虑一个比较低配的场景，那就不应该使用现代化技术，比如要兼容 iphone6 （手机端一般开发会使用 Vue 体系或者跨端，现代化技术很难沾边），所以大部分情况现代化打包都会是一个最优解。

关于这方面的内容，你可以从这里进行追溯：

《 使用swc与esbuild闪电加速你的webpack打包链路 》

🥰 所以，2022 年 swc/esbuild 不会取代 babel/terser

总结

我们并没有去细致入微的聊到 2021 年间大火的某个工具，比如 react-query ，更多聊的是会影响到 DX 、cicd 链路的内容，可以看到以上的每个设计点都会贯穿整个我们开发的全流程，深刻影响开发时的体验和打包质量、速度，是效能的关键。

我想强调的另一个点是：这并不是一个激进的方案，而是一个 2021 的普适方案，因为你可以从中看到，里面充满了四个大字：拥抱变化。

所以固执旧思维无法引领变革是一个落后的主要因素，另一个问题就是要进行变革需要有足够修炼的开发者引领，不过我相信任何开发者进行长期修炼后都可以完成这种 “普适” 的进阶，成为发生变革的人。

回顾 2021，我逐渐很少在文章中涉及到技术细节，这也是我 2021 年写作的一个变化趋势，因为我越来越相信体系化思考、价值判断、方向选择是目前进化的最优赛道，这并不意味着技术细节丢失，而是作为一个深度实践者、思考者的相信，因为相信，所以看见，因为相信，所以简单。