1.1 起源与生态定位：反虚拟DOM路线的由来

1.1 起源与生态定位：反虚拟 DOM 路线的由来

本节摘要：SolidJS 是 Ryan Carniato 基于细粒度响应式思想打造的前端框架，2021 年发布 1.0。它反对的不是 React 的语法，而是虚拟 DOM 这层运行时抽象：既然编译器能提前知道 JSX 的结构，更新就不必每次都重新描述再对账。理解这段历史，才能理解它后来把精力押在编译器、响应式内核与全栈方案上的取舍。

最初，Solid 并不是照着"又一个 React 替代品"的目标设计的。Ryan Carniato 长期研究 Knockout 一脉的细粒度响应式——那套早在 2010 年前后就出现的思路：状态自己知道自己被谁读取，变化发生时沿依赖关系精确通知。他当时的疑问很直接：细粒度响应式这么省事，为什么主流框架全在虚拟 DOM 上卷？答案逐渐清晰：不是细粒度响应式不好，而是它配上 JSX 这类自由语法时，依赖收集容易失控。于是 Solid 的路线定下来了——保留 JSX 的书写体验，但让编译器介入，把"看起来像 React"的代码翻译成"运行起来完全不同"的指令。

关键时间节点

图：SolidJS 发展时间线——从实验到提案

这条时间线上最值得注意的不是某个版本号，而是发布节奏背后的判断：Solid 迟迟不发 1.0，是在等编译器与响应式内核稳定——因为它选的路没有"运行时兜底"，接口一旦发布就很难反悔。相比之下，虚拟 DOM 框架可以把性能问题留给运行时慢慢优化，Solid 把宝押在了编译期，必须一次把地基打对。

它在框架版图上的位置

把主流方案按"响应式粒度"和"是否有虚拟 DOM"摆开，位置一目了然。React：组件级重渲染 + 虚拟 DOM 对账。Vue：Proxy 拦截的细粒度依赖收集 + 虚拟 DOM 对账（编译期做静态提升与补丁标记优化）。Svelte：编译期生成定向更新代码，运行时依赖图很薄。Solid：运行时细粒度响应式依赖图 + 编译期生成直通 DOM 的绑定，没有对账环节。

与 Vue 的血缘关系值得单独说。Vue 的 ref 加 computed 与 Solid 的 Signal 加 Memo 在心智上非常接近，Vue 用户迁移 Solid 的主要障碍反而小得多——主要就两条：Vue 保留了虚拟 DOM（所以 vdom 层的优化知识部分失效），以及模板语法换回了 JSX。而 React 用户要换的是世界观，语法却几乎不用换——这也是本册坚持对照式写法的原因：语法越像，心智越容易错位。

生态规模的差距要诚实面对。React 的组件库、模板、招聘市场体量仍然是断层第一，Solid 的第三方生态处于"核心库齐备、长尾欠缺"的状态：路由、状态、请求、无头组件库都有官方或社区答案，但某些细分领域（比如特定图表控件、成熟的后台模板）可能需要自己封装。第 7 章会给一张详细的生态对照矩阵，这里先立个坐标：选 Solid 不是选"更大的生态"，而是选"更少运行时开销与更小的依赖面"。

"快"的结构性原因

Solid 在 js-framework-benchmark 这类基准里常年处于第一梯队，很多教程把它归因为"没有虚拟 DOM"。这没错，但只说了表面。结构性原因可以拆成两点。

其一，更新路径短。React 一次状态变化要经历"重跑组件函数、重建元素对象、diff 对账、提交补丁"四个阶段；Solid 的信号直接触发绑定的写入函数，路径从"发布通知"到"改节点"一步到位。路径短意味着 CPU 少算、内存少分配、垃圾回收压力小——基准测试里创建大量行、局部更新这类操作，差距主要就在这里。

其二，开销前置到编译期。Solid 的 JSX 编译产物包含模板克隆：页面结构的静态部分在首次渲染时用 cloneNode 批量复制，动态部分只插入细粒度的绑定。静态结构不需要在每次更新时重新描述，这是虚拟 DOM 方案在运行时永远做不到的——它们的更新逻辑必须处理"任意结构都可能变"的最坏情况。

⚠️ 一个常见误读：基准测试测的是"框架开销"，不是"你的应用性能"。真实项目里，请求延迟、图片体积、首屏策略的影响往往比框架差异大一个数量级。第 8 章会展开这个话题。

本节带走什么

• Solid 的出身决定了它的气质：优先保证响应式内核与编译产物的确定性，再谈生态扩张。
• 它与 Vue 同属细粒度响应式家族，与 React 同享 JSX 语法；血缘与语法各像一半，这正是对照学习的价值所在。
• 性能优势来自"更新路径短 + 开销前置"两条结构性原因，不是玄学。

常见追问：定位层面的三个高频问题

问题：Solid 与 React 有没有从属或合作关系？

没有。两者是完全独立的项目，只是共享 JSX 语法与函数组件的书写习惯。Solid 的作者多次公开比较两条路线，但代码层面零共享。把"像 React"理解成迁移友好设计即可，不要理解成衍生关系——这决定了你搜资料时该按哪套关键词找。

问题：它为什么坚持不兼容 React 生态？

不是不能，而是不愿付那个代价。兼容 React 的运行时组件意味着必须实现组件重渲染与协调器，等于把虚拟 DOM 的账单请回来——这与项目的存在理由冲突。Solid 选择的兼容层次在语法与类型习惯上（JSX、事件命名风格、TypeScript 体验），在运行时模型上彻底分家。理解了这一点，就理解了第 7 章生态矩阵里"必换"行的由来。

问题：发布这么多年，它还活跃吗？

判断项目健康度看三个信号：内核缺陷的响应速度、元框架的迭代节奏、标准提案的参与度。三个信号在 Solid 身上都处于健康区间——尤其是它深度参与跨框架的信号标准化讨论，这类位置只有"被行业需要"的项目才拿得到。

生态位小结

把本节压缩成一张随身卡片：Solid 是"运行时细粒度响应式加编译期模板"路线的代表，与 Vue 同源（响应式哲学）、与 React 同皮（JSX 语法）、与 Svelte 同靶（直改 DOM）。它的性能口碑有结构性依据，它的生态规模有结构性短板，两者都源自同一个选择：把复杂性从运行时挪到编译期。后面所有章节都在为这张卡片补充细节与证据。

下一节把这张定位图翻译成一张可以直接对照查阅的术语表，并用一段代码验证本章最反直觉的论断：组件函数只执行一次。