文章目录SolidJS不用虚拟 DOM如何实现接近原生 JavaScript 的更新性能从虚拟 DOM 的更新流程说起Solid 的更新流程1. JSX 在编译阶段变成真实 DOM 操作2. Signal 建立精确的依赖关系3. 组件通常只执行一次一次状态更新究竟省掉了什么减少重复计算避免虚拟节点分配避免通用树级 Diff缩小更新作用域派生状态也保持细粒度动态列表仍然需要协调为什么性能能够接近原生 JavaScript适合哪些应用总结SolidJS不用虚拟 DOM如何实现接近原生 JavaScript 的更新性能SolidJS 是一个面向现代 Web 应用的声明式 UI 框架。它使用与 React 类似的 JSX 语法却采用了完全不同的渲染机制JSX 在编译阶段被转换成真实 DOM 操作运行时再通过细粒度响应式系统只更新真正依赖变化状态的 DOM 节点。因此Solid 不需要在每次状态变化后重新执行整个组件也不需要创建一棵新的虚拟 DOM 树进行比较。官方将这种模式概括为将模板编译为真实 DOM 节点并通过细粒度响应式机制更新它们。SolidJS 官方仓库从虚拟 DOM 的更新流程说起采用虚拟 DOM 的框架状态变化后的典型流程是状态变化 ↓ 重新执行相关组件 ↓ 生成新的虚拟 DOM 对象 ↓ 与上一棵虚拟 DOM 做 Diff ↓ 计算变更 ↓ 更新真实 DOM虚拟 DOM 的价值在于提供一种通用、声明式的 UI 更新模型。开发者只需要描述“界面现在应该是什么样子”框架负责找出变化。但这一过程也存在运行时成本组件函数可能需要重新执行。需要创建大量临时虚拟节点对象。需要遍历和比较新旧节点树。临时对象会带来额外内存占用和垃圾回收压力。即使最终只修改一个文本节点框架也可能需要先检查一片组件子树。需要强调的是虚拟 DOM 并不等于性能差。成熟框架会通过批处理、静态提升、调度和跳过渲染等方式降低成本。Solid 的不同之处在于它从架构上绕过了“重新生成 UI 树再比较”这条路径。Solid 的更新流程Solid 的状态更新更接近下面这条路径Signal 发生变化 ↓ 找到订阅该 Signal 的计算 ↓ 重新执行这些计算 ↓ 直接修改对应的 DOM 属性、文本或节点这里不存在新的虚拟 DOM 树也不需要执行通用的树级 Diff。其核心由三个机制共同实现编译时处理 JSX、Signal 依赖追踪以及直接 DOM 更新。1. JSX 在编译阶段变成真实 DOM 操作Solid 的 JSX 看起来很像 Reactimport { createSignal } from solid-js; function Counter() { const [count, setCount] createSignal(0); return ( button onClick{() setCount(count() 1)} Count: {count()} /button ); }但 JSX 只是表面语法相似编译结果完全不同。React JSX 通常会变成创建元素描述对象的调用Solid 编译器则会分析模板中的静态与动态部分并生成近似下面这样的代码constbuttoncreateButtonFromTemplate();button.addEventListener(click,(){setCount(count()1);});createReactiveBinding((){buttonText.dataCount:${count()};});returnbutton;这不是 Solid 编译器的逐字输出而是其工作方式的简化表达。编译器提前知道button是一个固定的真实 DOM 元素。点击事件只需注册一次。Count:是静态内容。只有{count()}是动态区域。该动态区域最终对应哪个文本节点。静态 HTML 可以被提取为模板并直接克隆动态表达式则被转换成定向更新逻辑。Solid 的 JSX 会直接产生 DOM 元素而不是运行时虚拟节点。SolidJS JSX 文档2. Signal 建立精确的依赖关系Solid 细粒度响应式系统的基础是createSignalconst[count,setCount]createSignal(0);它返回两个函数count()读取当前值同时在响应式上下文中登记依赖。setCount()修改值并通知依赖它的计算。当模板执行到span{count()}/spanSolid 会记录一条关系count Signal → span 中的文本更新逻辑如果另一个地方使用了同一个 Signalstrong{count() * 2}/strong依赖图就会变成count Signal ├── 更新 span 的文本 └── 更新 strong 的文本调用setCount(1)时Solid 不需要从应用根节点开始寻找变化。Signal 自己保存了订阅者可以直接通知这两个更新逻辑。Signal getter 会在响应式上下文中收集依赖setter 则通知相关计算这正是 Solid 响应式系统的基础。createSignal官方文档3. 组件通常只执行一次这是 Solid 与 React 最容易被忽略的差别。在 React 的函数组件模型中状态更新通常意味着组件函数再次执行而在 Solid 中组件函数主要负责创建状态与响应式计算。创建真实 DOM。建立状态到 DOM 的依赖关系。初始化完成后组件函数通常不会因为内部 Signal 更新而再次执行。SolidJS 组件生命周期文档例如function Counter() { const [count, setCount] createSignal(0); console.log(组件初始化); return ( button onClick{() setCount(count() 1)} {count()} /button ); }无论按钮点击多少次console.log通常只会在该组件实例创建时执行一次。后续变化只会触发读取了count()的响应式绑定。所以Solid 中所谓的“重新渲染”准确地说往往不是重新执行组件或重新创建节点而是执行一次类似这样的原生操作textNode.dataString(newCount);一次状态更新究竟省掉了什么环节常见虚拟 DOM 模型Solid组件函数可能重新执行通常只在创建时执行中间表示创建新的虚拟节点直接持有真实 DOM查找变化比较新旧节点树Signal 通知订阅者更新范围组件或子树级别表达式、属性或文本节点级别临时对象可能产生大量 VNode通常更少DOM 提交Diff 后统一提交定向执行 DOM 操作这种设计主要减少了四类开销减少重复计算组件中与本次状态变化无关的代码不必重新执行。只有真正读取了变化 Signal 的计算才会运行。避免虚拟节点分配Solid 不需要为每次更新重新创建整片虚拟节点对象因此通常能够减少短生命周期对象以及相应的垃圾回收压力。避免通用树级 Diff编译器已经知道动态表达式对应哪个 DOM 位置运行时不必通过比较两棵树重新发现它。缩小更新作用域修改一个文本值时工作量可以接近一次原生 DOM 属性赋值而不是一次组件级重新渲染。派生状态也保持细粒度Solid 使用createMemo缓存派生计算const [price, setPrice] createSignal(100); const [quantity, setQuantity] createSignal(2); const total createMemo(() price() * quantity()); return div总价{total()}/div;依赖关系为price ──┐ ├── total Memo ── DOM 文本 quantity┘只有price或quantity改变时total才需要重新计算而且只有total的结果发生有效变化时下游 DOM 才需要继续更新。createEffect采用相同的自动依赖追踪机制执行过程中读取了哪些响应式值就订阅哪些值依赖改变时才重新执行。createEffect官方文档动态列表仍然需要协调“不使用虚拟 DOM”不代表任何场景都完全不需要比较。列表插入、删除和重新排序时Solid 仍然需要判断哪些项目被添加或删除哪些现有 DOM 节点需要移动哪些索引或项目内容发生变化。区别在于这种协调由For、Index等专门的控制流组件局部完成而不是每次更新都对整棵 UI 树进行通用 Diff。例如For在项目移动时可以复用并移动已有 DOM 节点。SolidJS 列表渲染文档为什么性能能够接近原生 JavaScript因为编译后的 Solid 程序本质上非常接近开发者手写的命令式 DOM 代码constspandocument.createElement(span);span.textContentString(count);functionupdateCount(next){countnext;span.textContentString(next);}Solid 在此基础上增加了声明式 JSX、自动依赖追踪、生命周期管理、批量更新和组件抽象。它的目标不是让浏览器执行另一套 UI 树系统而是帮助开发者自动生成高效的原生 DOM 操作。不过“接近原生 JavaScript”应被理解为一种架构优势和基准测试表现而不是所有应用中的绝对保证。实际性能仍然取决于响应式依赖数量和更新频率DOM 结构复杂度列表更新方式是否进行了昂贵的业务计算浏览器布局、绘制和合成成本开发者是否正确使用 Signal、Store 和控制流组件。Solid 省掉的是框架层的大量协调工作却无法消除浏览器本身的布局与绘制开销。适合哪些应用Solid 特别适合高频更新的数据看板和实时监控界面大量独立交互单元组成的复杂页面对启动速度、内存和低端设备性能敏感的应用可视化编辑器、表格、交易终端等高交互产品熟悉 JSX但希望获得更直接 DOM 更新模型的团队。它需要开发者适应的主要变化是虽然语法像 React但运行模型不是 React。Signal 通过函数读取组件不是依靠反复执行来刷新Props 也应当保持响应式访问。直接照搬 React 的解构、条件判断和副作用习惯可能会意外丢失响应性。总结Solid 的性能优势并不只是因为“没有虚拟 DOM”而是因为它建立了一条更短的更新路径编译器提前确定 DOM 结构Signal 在运行时记录精确依赖状态变化后直接执行对应的 DOM 更新。换句话说Solid 把原本需要在运行时反复完成的“创建节点描述、重新执行组件、比较节点树”工作分别交给了编译阶段和细粒度响应式依赖图。最终开发者仍然可以使用熟悉、声明式的 JSX而浏览器执行的却是接近手写原生 JavaScript 的定向 DOM 操作。这正是 SolidJS 在保持良好开发体验的同时能够实现低更新开销与较低内存占用的核心原因。