1. 项目缘起为什么我要从零开始造一个前端引擎做前端开发十几年从 jQuery 时代一路干到 React、Vue 三分天下我经手过的大大小小项目少说也有上百个。这几年随着业务越来越复杂一个感受特别明显现有的框架在应对某些特定场景时总有些“隔靴搔痒”。要么是打包后的体积在性能敏感的移动端成了负担要么是在需要极致渲染性能的富交互场景下显得力不从心再或者当你想深度定制一些底层渲染逻辑时发现框架黑盒太多无从下手。去年团队接了一个大型数据可视化仪表盘的项目需要同时渲染成千上万个动态数据点并且要求丝滑的动画交互。我们尝试了主流的几个方案React Canvas 库、Vue WebGL 封装但总是在性能、灵活性和开发体验之间难以取得完美平衡。要么为了性能牺牲了声明式的开发便利要么为了便利性而不得不接受帧率上的妥协。就在反复折腾和权衡中一个念头越来越清晰为什么不自己动手打造一个更贴合我们这类场景的“前端引擎”这里说的“引擎”不是指 Unity、Unreal 那种完整的游戏引擎而是一个更聚焦于 Web 前端特定领域比如高性能 UI 渲染、复杂状态同步、特定类型应用架构的核心运行时框架。它应该像汽车的引擎一样提供最核心的动力渲染与计算至于车身样式组件库、内饰业务逻辑则可以更灵活地搭配。这个想法听起来很疯狂但当你对现有工具的理解深入到一定程度并且有明确的、未被满足的需求驱动时造轮子就不再是重复劳动而是一次有价值的底层探索和技术储备。2. 核心设计思路定义我们自己的“引擎”边界决定动手之后第一个问题就是这个引擎到底要解决什么边界在哪里我们不能做一个大而全的“React 替代品”那既不现实也没必要。经过团队多次讨论我们明确了几个核心设计原则这决定了后续所有技术选型的方向。2.1 目标场景与核心诉求我们的引擎主要瞄准两类场景高性能、高密度数据渲染的应用如实时数据监控大屏、金融交易终端、复杂图表编辑工具。这类应用对渲染帧率、内存占用和首次加载速度有极致要求。需要高度定制化渲染流程的应用比如一些非标准的 UI 渲染非 DOM 流、与特定原生模块如音视频处理、硬件加速计算深度绑定的 Hybrid 应用。基于这些场景我们提炼出三个核心诉求极致的运行时性能减少不必要的抽象层让关键路径虚拟 DOM Diff、渲染指令提交尽可能短平快。精细化的资源与生命周期控制开发者能清楚地知道一个组件何时被创建、更新、销毁并能手动干预内存回收、DOM 节点复用等。可插拔的渲染后端核心逻辑与具体渲染目标解耦。今天可以渲染到 DOM明天就能通过替换“渲染器”渲染到 Canvas 2D、WebGL 甚至服务端SSR。2.2 架构选型在“重”与“轻”之间寻找平衡市面上主流框架的架构给了我们很多启发但也暴露了一些我们想避免的问题。React 的启发与规避React 的声明式、组件化思想和强大的生态是标杆。但我们希望虚拟 DOM 的 Diff 算法可以更激进支持类似key但更灵活的节点复用策略并且简化 Hooks 的心智模型使其在频繁更新时更可预测。Vue 3 的借鉴Vue 3 的响应式系统Proxy和编译时优化如静态提升是非常优秀的设计。我们决定借鉴其“编译时 运行时”协同的思路在构建阶段就分析模板/JSX 的静态结构生成更优化的运行时代码。Svelte 的激进思路Svelte “编译器即框架”的理念很吸引人它将大量工作挪到编译时产出的代码几乎没有运行时框架开销。我们部分采纳了这个思想但保留了一个轻量级的运行时内核用于处理编译时无法确定的动态逻辑。最终我们的架构定为“强类型约束的响应式内核 模板编译优化 多渲染器适配”。内核非常小只负责创建响应式数据图和调度更新。模板或 JSX 通过编译器转化为对内核 API 的直接调用并嵌入优化指令。渲染器作为一个独立包接收内核的更新指令将其转化为 DOM 操作或 Canvas 绘制命令。2.3 技术栈锚定为什么选择 TypeScript 和 Node.js 生态这是一个没有悬念的选择。从项目启动第一天我们就确定使用TypeScript作为开发语言。注意对于底层库或框架开发类型系统不是可选项而是必需品。它能在编码阶段就捕获大量潜在的错误特别是数据流复杂的场景同时其类型声明本身就是最好的文档。我们的引擎内核 API 设计重度依赖 TypeScript 的泛型、条件类型等高级特性来提供优异的开发者体验。构建工具链则完全基于Node.js生态。这同样是必然选择编译器编写我们使用babel/parser和babel/traverse来解析和转换 JSX/模板语法利用babel/generator生成目标代码。Babel 生态成熟插件体系丰富能极大降低编译器开发的复杂度。打包与发布使用Rollup进行库的打包。Rollup 对 Tree-shaking 的支持天生友好能帮助我们生成最精简的、按需引入的产物。配合tsc生成类型声明文件整个流程非常顺畅。开发体验Vitest进行单元测试速度快对 TypeScript 和 ESM 支持好。ESLintPrettier保证代码风格统一。这一切都构筑在 Node.js 之上。关于网络热词中提到的DeepSeek在我们开发过程中它确实扮演了“高级助手”的角色。当我们需要为某个复杂算法比如一个改良的虚拟 DOM Diff 策略编写类型定义或撰写清晰的注释文档时会使用类似 DeepSeek 这样的 AI 编码助手来提供草稿或灵感但核心逻辑和代码必须由我们自己掌控和审查。AI 是很好的“加速器”但绝非“决策者”。3. 内核实现打造一个高性能的响应式系统引擎的核心是响应式系统它负责自动追踪数据依赖并在数据变化时精准地通知到依赖它的组件进行更新。我们的目标是设计一个既快又省内存的系统。3.1 响应式数据结构的实现我们没有直接使用 JavaScript 原生Proxy因为在某些对性能极其苛求的循环更新场景中Proxy的拦截开销仍可测量。我们实现了一个基于Object.defineProperty针对已知字段和Value Holder针对动态访问的混合系统。// 简化的核心响应式对象实现 class ReactiveObjectT extends object { private _value: T; private _deps: MapPropertyKey, Dep new Map(); // 依赖收集器 constructor(target: T) { this._value target; for (const key in target) { if (Object.prototype.hasOwnProperty.call(target, key)) { this._defineReactive(key, target[key]); } } } private _defineReactive(key: PropertyKey, val: any) { const dep new Dep(); // 每个属性一个依赖管理器 Object.defineProperty(this._value, key, { enumerable: true, configurable: true, get: () { if (Dep.currentWatcher) { dep.depend(); // 收集当前正在执行的观察者如渲染函数 } return val; }, set: (newVal) { if (newVal ! val) { val newVal; dep.notify(); // 通知所有依赖该属性的观察者更新 } }, }); this._deps.set(key, dep); } get value(): T { return this._value; } }这个实现的关键在于Dep依赖类和currentWatcher当前观察者的全局标记。当一个组件的渲染函数执行时它会被设置为currentWatcher。函数内访问任何响应式属性时属性的getter会将这个currentWatcher收集到自己的dep中。当属性值变化时dep会通知所有收集到的watcher重新执行。3.2 依赖收集与派发更新的优化简单的“属性 - 观察者”映射在复杂场景下会导致过度更新。例如一个计算属性依赖了 A 和 B当 A 变化时计算属性更新是合理的但如果一个组件只依赖了计算属性而不直接依赖 A那么 A 的变化不应该直接通知这个组件而应该通过计算属性“中转”。我们引入了“依赖层级”和“脏检查标记”的概念。计算属性Computed本身也是一个“观察者”它会收集其依赖的响应式属性的dep。同时它自己也有一个dep被那些依赖它的组件或其它计算属性收集。当底层响应式数据变化时会沿着依赖链向上“标记”所有相关的计算属性为“脏”dirty但不会立即触发它们的重新计算。在下一个微任务或动画帧中引擎会执行一个“更新调度”。调度器会检查所有“脏”的计算属性按依赖顺序重新计算它们。只有计算结果真正发生变化时才会通知依赖它们的组件进行更新。这个机制避免了“级联爆炸”式的无效更新在状态复杂时提升显著。实操心得在实现响应式系统时一定要为依赖关系图设计可视化的调试工具。我们开发了一个简单的浏览器插件可以将当前页面中所有响应式对象、计算属性和组件之间的依赖关系以图谱形式展示出来。这在排查“为什么这个组件更新了”或“为什么这个组件没更新”的问题时是无比强大的神器。3.3 与渲染器的桥接更新调度器内核不关心具体怎么渲染它只负责在正确的时机调用组件的更新函数。我们实现了一个基于Promise.resolve().then()微任务和requestAnimationFrame动画帧的双缓冲调度器。同步更新对于用户交互如点击触发的状态变更我们希望在下一个微任务中就进行组件重新计算和 DOM 更新以保证响应的即时性。异步批处理如果在同一个事件循环中多次修改状态调度器会将这些更新合并为一次组件更新避免不必要的中间渲染。动画帧对齐对于由requestAnimationFrame驱动的连续状态更新如动画调度器会确保组件的渲染发生在同一个动画帧中与屏幕刷新同步避免丢帧。调度器的 API 设计得很简洁class Scheduler { private static queue: SetComponent new Set(); private static isFlushing false; static scheduleUpdate(comp: Component) { this.queue.add(comp); if (!this.isFlushing) { this.isFlushing true; // 优先尝试使用微任务否则降级到 setTimeout Promise.resolve().then(() this.flushUpdates()); } } private static flushUpdates() { const updates Array.from(this.queue); this.queue.clear(); // 对更新进行排序例如父组件优先于子组件 updates.sort((a, b) a.depth - b.depth); for (const comp of updates) { comp._update(); // 触发组件实际更新 } this.isFlushing false; } }4. 模板编译器从声明式到高性能命令式代码我们的模板语法类似 Vue 的单文件组件但更精简。编译器的任务是将声明式的模板编译成高效的、直接操作响应式系统和渲染器的命令式 JavaScript 代码。4.1 编译流程概览解析Parse将模板字符串解析成抽象语法树AST。我们扩展了babel/parser使其能识别我们的模板指令如v-if,v-for,event。转换Transform这是核心优化阶段。遍历 AST进行多项优化静态提升Static Hoisting将纯静态的节点如div classcontainer提取到渲染函数外部只创建一次避免每次渲染都重复创建 VNode。补丁标志Patch Flags分析动态绑定。如果一个节点只有class是动态的就在生成的 VNode 上标记PatchFlags.CLASS。这样在 Diff 时渲染器可以跳过对该节点子节点或属性的全量对比直接更新class即可。区块树Block Tree将模板划分为稳定的“区块”。对于v-if/v-else、v-for这种可能改变节点结构的指令将其包裹的节点树作为一个“区块”。更新时以区块为单位进行 Diff而不是全树 Diff大大减少了比较范围。代码生成Codegen将优化后的 AST 转换为渲染函数的 JavaScript 代码字符串。生成的代码直接调用内核的h创建 VNode、createBlock等运行时帮助函数。4.2 关键优化Patch Flags 实战假设一个模板片段div :class{ active: isActive } :styledynamicStyles {{ message }} /div经过编译器的转换分析它会识别出这个节点有三个动态绑定class、style和文本message。生成的 VNode 创建代码大致如下// 伪代码展示概念 import { createVNode, PatchFlags } from ../runtime-core/vnode; function render(_ctx) { return createVNode( div, { class: _ctx.isActive ? active : null, style: _ctx.dynamicStyles }, _ctx.message, // 子节点是文本 // 关键的 Patch Flag PatchFlags.CLASS | PatchFlags.STYLE | PatchFlags.TEXT ); }在渲染器的 Diff 阶段它看到这个PatchFlags就知道只需要检查class、style和文本内容是否需要更新而完全跳过对div的其他属性如id、>// 简化的 Canvas 渲染器接口 interface CanvasRenderer { createElement(type: string): CanvasNode; // 创建一个 Canvas 节点非 DOM setProperty(node: CanvasNode, key: string, value: any): void; // 设置属性如 fillStyle, text insert(parent: CanvasNode, child: CanvasNode): void; // 将子节点加入绘制列表 remove(child: CanvasNode): void; // 核心将节点树转换为绘制命令并执行 commitUpdate(root: CanvasNode): void; } class CanvasNode { type: rect | text | circle; props: Recordstring, any; children: CanvasNode[] []; // 对应的 Canvas 绘制命令缓存 drawCommands: Function[] []; }当内核通知 Canvas 渲染器更新时渲染器遍历 VNode 树为每个节点生成或更新对应的CanvasNode及其drawCommands。在commitUpdate阶段它清空画布然后按顺序执行所有节点的绘制命令。虽然功能简单但它证明了核心与渲染分离架构的威力——业务逻辑组件无需修改只需切换渲染器就能从 DOM 应用变为 Canvas 应用。6. 开发体验与生态建设思考一个引擎能否成功技术先进性只占一半另一半是开发体验和生态。我们从一开始就关注这些。6.1 调试工具DevTools开发我们开发了一个浏览器扩展形式的 DevTools它包含以下面板组件树以树形结构展示当前页面的组件层次可以查看每个组件的 props、state。时间旅行记录每一次状态变更可以回退到任意历史状态用于复现 Bug。性能分析可视化展示组件渲染耗时、更新次数帮助定位性能瓶颈。依赖图谱如前所述可视化展示响应式数据的依赖关系。开发 DevTools 的关键是与引擎内核的通信。我们在内核中注入了一个轻量的devtools模块它通过window.postMessage或chrome.runtime.connect与扩展进行通信传递组件树、状态变更等数据。6.2 类型安全的极致追求我们利用 TypeScript 的高级类型为组件提供了近乎完美的类型推断。Props 类型推导组件的props定义会自动推断出传入的 props 类型。模板内表达式类型检查通过 TypeScript 的语言服务插件我们实现了在模板内对{{ expression }}和:propexpression中表达式的类型检查。如果表达式返回的类型与预期不符会在 IDE 中直接报错。事件处理器类型eventhandler中的handler函数其参数能自动推断为对应事件对象的正确类型如MouseEvent。这些类型支持极大地提升了开发效率和代码可靠性让许多运行时错误在编写代码时就被发现。6.3 对标与展望我们不是要取代谁在开发过程中我们不断对比 React、Vue、Svelte 等框架。我们清醒地认识到这个引擎的目标不是取代它们而是在它们覆盖不到的细分领域高性能渲染、深度定制提供一个更专注的解决方案。它的 API 设计有意地保持精简和底层学习曲线会更陡峭但换来的控制力也更强。与热门技术的结合思考React Server Components (RSC)服务端组件的理念很棒。我们的引擎架构天然支持 SSR未来可以考虑在编译阶段区分客户端/服务端组件实现部分组件的服务端渲染与流式传输。WebAssembly (Wasm)对于引擎中计算密集型的部分如复杂的布局计算、特定的 Diff 逻辑可以考虑用 Rust 编写并编译为 Wasm以获得近原生性能。构建工具链我们的编译器可以更深度地与 Vite 集成实现基于依赖的按需编译甚至探索“Bundle-less”的开发模式。这个项目目前仍在进行中但它已经为我们团队的核心产品带来了可观的性能提升和开发模式的革新。更重要的是通过亲手打造一个前端引擎我们对现代前端框架的理解不再浮于表面而是深入到了骨髓。每一次性能调优每一个 API 设计决策都让我们对“如何构建一个高效、可维护的大型前端应用”有了更深刻、更本质的认识。这或许就是“造轮子”最大的价值——不是为了取代别人而是为了超越过去的自己。
