01｜React 赢得越彻底，它留下来的默认重量就越容易被重新审问
前两篇讲的是框架为什么会出现，
前一篇讲的是 React 和 Vue 怎样分别拿到主流秩序位置。
可历史到了这里，并不会自然停下。
因为每一代框架胜利之后，
都会留下新的默认成本。
React 也一样。
它把很多事情重写得更统一：
- 组件化
- 状态驱动视图
- 单向数据流
- 整套生态接口
可与此同时，
它也把另一类东西慢慢推成了新默认：
- 更重的运行时参与
- 更强的重新渲染心智
- 更多围绕 Virtual DOM 的工作
- 更多为了性能而额外学习和调优的负担
这些东西在 React 上升期都能被接受，
因为当时它解决的旧问题更大。
但一旦整套心智成了主流，
新的追问就会自然冒出来：
声明式 UI 当然很对，可为了这份声明式，我们是不是已经给运行时交了太多税？
这就是 Svelte、Signals、细粒度响应式重新抬头的真正背景。
它们争的不是“能不能更潮”。
它们争的是：
React 时代的默认成本，到底是不是已经该被重估了。
02｜Svelte 的厉害，不只是它反 Virtual DOM，而是它公开把问题重新提了一遍
Svelte 这条线特别有戏，
因为它不是悄悄换条技术路线。
它是公开掀桌。
Rich Harris 那篇 Virtual DOM is pure overhead，
标题本身就非常强势。
它不是温和讨论：
“我们有另一种实现。”
它直接是在说：
你们这套默认常识本身就该被怀疑。
这篇文章真正值得写的，不只是态度很猛。
而是它把一个长期被压住的问题重新摆回台面：
Virtual DOM 当然不是毫无价值，
它解决了声明式 UI 在现实里的落地问题。
但如果每一轮更新都还要先在运行时做一整层对比与协调，
这份成本是不是可以更早被处理掉？
于是 Svelte 给出的答案是：
可以。把更多工作前移给编译器。
这就是为什么 Svelte 真正值得写的，不是“写法清爽”。
而是：
它重新分配了复杂度的位置。
不再默认交给运行时。
而是尽量交给编译时。
03｜Svelte 3 最狠的一句，其实不是性能口号，而是“最好的 API 是没有 API”
在 Svelte 3: Rethinking reactivity 里，
Rich Harris 有一句特别值得记：
the best API is no API at all
这句话为什么重要？
因为它背后的野心，不只是减少几个函数调用。
而是在反问：
响应式这件事，为什么一定要通过额外运行时抽象和额外心智负担来表达？
Svelte 3 想做的是把一部分响应式工作重新塞回语言使用体验里。
比如让你写：
count += 1
而不是总要显式调用某种特别的状态更新协议。
这意味着什么？
意味着它在争另一种合法性：
框架不一定要把自己表现得越来越像一个厚重运行时，它也可以尽量把自己藏进编译过程。
这和 React、AngularJS 那些时代的主流直觉非常不一样。
因为它直接把框架价值重新定义成：
不一定是“运行时替你做更多事”，而可以是“编译器提前替你把很多事消化掉”。
这就是 Svelte 路线最锋利的地方。
不是“更小更快”这么简单。
而是它重新提案：
框架到底应该以什么形态存在。
04｜Signals 的重新流行说明，React 时代的问题意识已经外溢了
如果说 Svelte 更像从“编译器 vs 运行时”这条线公开反攻，
那 Signals 更像另一种路线：
既承认响应式是核心问题，又不想接受整块重新渲染的默认代价。
Signals 当然不是凭空出现的新思想。
依赖跟踪、响应式、细粒度更新，这些想法以前都存在。
可 Signals 这几个字最近几年重新变热，
特别值得注意。
因为这说明整个生态都在重新问同一件事：
当状态发生变化时，到底有没有必要让那么大一片 UI 跟着走完整套协调流程？
Preact Signals 的文档里说得很直接：
它们是 reactive primitives，
强调的是自动依赖跟踪、直接绑定和更细的更新粒度。
而官方博客 Signal Boosting 又特别提到，
Signals 这套说法本身就受到了 SolidJS、Vue、Svelte 这类响应式传统的影响。
也就是说，Signals 的上升很说明问题：
它不是某一家的小技巧。
而是：
React 时代塑造出来的默认问题意识，已经逼着整个生态去重新寻找更细粒度的更新答案。
05｜所以这轮新战争真正争的，不是“谁 benchmark 更快”，而是复杂度该压给谁
这是这一篇最重要的判断。
因为一说到 Svelte、Signals、Solid、细粒度响应式，
很多讨论很容易立刻滑到 benchmark。
可如果只停在“谁更快”，这篇就会写废。
因为真正值得写的根本不是跑分。
而是：
同一份声明式 UI 的复杂度，最后到底应该放在哪一层。
React 一代给出的主流答案，大致是：
- 组件声明 UI
- 状态变化触发重新渲染
- 运行时协调差异
Svelte 的反问是：
- 既然编译时能知道更多，为什么不提前展开更多工作
Signals 一类路线的反问是：
- 既然依赖关系可以更细，为什么不更精确地更新
这就说明，
今天框架战争最深的层面其实已经回到了一个老问题：
复杂度消失不了，那它该被安排到运行时、编译器，还是依赖图本身？
这才是这轮反攻真正值钱的地方。
不是口水。
是重新分账。
06｜这轮反攻也没有推翻 React，但它确实逼着大家重新谈“默认值”
这里也不能写成“新路线正在取代旧王朝”的简单戏码。
因为现实远没这么干净。
React 仍然很强，
生态、工具链、人才市场、文档入口都还在它那边。
可这不代表这轮反攻没有意义。
恰恰相反，
它最重要的意义可能是：
它逼着整个框架世界重新思考默认值。
以前很多东西可以被当作不证自明：
- Virtual DOM 够快
- 重新渲染是自然方案
- 运行时多做点事没问题
而现在这些默认前提都开始被系统性重问。
一旦默认前提开始被重问，
哪怕旧秩序没立刻被掀翻，
战争也已经重新开打了。
这就是为什么我更愿意把这一阶段理解成：
React 时代之后的一次问题意识反攻。
不是大家统一投奔了某个新王者。
而是很多人开始不再愿意无条件接受旧王者留下来的那套默认成本。
07｜这轮反攻没有结束，它已经变成今天的默认追问
为什么这篇值得放进主线，而不是写成技术小番外？
因为这轮争论今天已经深到会影响大家日常理解框架。
比如：
- 大家重新关心编译时优化是不是核心路线
- 大家越来越能接受“细粒度响应式”是一种底层优势
- 大家更在意框架有没有把不必要的工作交给运行时
- 大家会重新问：框架到底应该显得多重，才算合理
这些问题说明，
前端框架战争从来没有结束。
它只是从以前的：
- 模板 vs 组件
- 双向绑定 vs 单向数据流
继续走到了今天的：
- 运行时 vs 编译时
- 粗粒度协调 vs 细粒度更新
所以下一篇要做的，就是把整套系列拉回今天的现实：
为什么框架最后已经不只是 UI 工具，而是长成了现代前端默认的治理层。
参考与延伸阅读
Virtual DOM is pure overhead
https://svelte.dev/blog/virtual-dom-is-pure-overheadSvelte 3: Rethinking reactivity
https://svelte.dev/blog/svelte-3-rethinking-reactivityRich Harris - Rethinking reactivity
https://www.youtube.com/watch?v=AdNJ3fydeaoSapper: Towards the ideal web app framework
https://svelte.dev/blog/sapper-towards-the-ideal-web-app-frameworkIntroducing Signals - Preact
https://preactjs.com/blog/introducing-signalsSignals | Preact Guide
https://preactjs.com/guide/v10/signalsSignal Boosting
https://preactjs.com/blog/signal-boostingSignals | Angular
https://angular.dev/guide/signalsSignals | SolidJS Docs
https://docs.solidjs.com/concepts/signals