你旧的理解(框架 = UI / 加载速度 / 交互体验)没有错,但它停在了"框架做什么"。要理解今天的框架之争,得往下挖一层:框架替你决定了"代码与状态的组织方式",以及"哪些活在哪台机器上跑"。
你过去接触的框架(jQuery、Bootstrap 时代,甚至早期 Vue/React 的认知),解决的是同一个问题:怎么把页面画出来、让它动起来。这是"视图层"问题——DOM 操作、动画、加载速度、交互反馈。
但现代前端框架早已越过这条线。今天的 React、Next.js、TanStack 真正在替你回答的,是三个架构问题:
"状态住在哪里、谁来管它?" · "代码该如何切分与组织?" · "哪些逻辑在浏览器跑、哪些在服务器跑?"
UI 和速度反而成了这三个答案的副产品。一旦你用这三个问题去看框架,所有差异瞬间清晰——因为框架本质上是一套关于"如何组织一个应用"的预设答案。
框架是一组预先做好的架构决策 + 配套约定 + 现成机件。它用"放弃一部分自由"换取"不用每次从零造轮子"。库(library)是你调用它;框架是它调用你——它定义骨架和生命周期,你往预留的槽位里填代码。这就是著名的"好莱坞原则:别打给我们,我们会打给你"。
所以"选框架"从来不是选"哪个画 UI 更快",而是选"我愿意接受谁替我做的那套架构决策"。这也是为什么 TanStack 和 Next.js 的争论核心是哲学(平台 vs 原语),而不是渲染速度。
把"框架"这个词拆成三层,你就能给任何框架精确定位。
怎么描述 UI、怎么响应用户操作、怎么高效更新页面。React 的核心创新——声明式 UI + 虚拟 DOM + 单向数据流——就在这层。你只描述"数据是这样时,界面应该长这样",框架负责算出怎么改 DOM。这层决定了交互体验和渲染性能,是你熟悉的领域。
这是从"页面"升级到"应用"的分水岭。状态分两种,务必分清:
很多人把这两者混在一起用一个 Redux 硬扛,代码就臃肿了。理解这条分界,是理解半个现代前端生态的钥匙。
同一段代码,可以在三个不同的地方、三个不同的时间执行——这是现代"全栈框架"概念的核心,也是你旧理解里完全缺失的一层。下面单独展开。
这一层是 Next.js、TanStack Start 这类"全栈框架"和老式纯前端框架的根本分野。同一个组件,渲染时机有三种:
| 模式 | 在哪/何时渲染 | 擅长 | 代价 |
|---|---|---|---|
| CSR 客户端渲染 | 浏览器,运行时 | 交互丰富的应用、登录后页面 | 首屏慢、SEO 差 |
| SSR 服务端渲染 | 服务器,每次请求时 | 需即时数据 + SEO | 服务器有负载 |
| SSG 静态生成 | 服务器,构建时(提前) | 博客、营销页、文档 | 内容更新需重新构建 |
再叠加 水合(hydration)这个关键概念:服务器先吐出静态 HTML(用户秒看到内容),浏览器再"注入"JS 让它变得可交互。React Server Components(RSC)则更进一步——让一部分组件只在服务器跑、永不发到浏览器,从而减少发给用户的 JS。
这就解释了你之前看到的争论:Next.js 押注 RSC(服务端优先、自动优化但心智复杂);TanStack Start 用传统 SSR + 完整水合(更简单可预测,但没有 RSC 的 JS 瘦身)。"在哪跑"这个看不见的决定,直接决定了首屏速度、SEO、服务器成本和代码复杂度——它远比"UI 好不好看"重要。
有了三层模型,选型就不再靠感觉。问自己这串问题,答案会把你导向正确的框架:
把它落成几句可操作的判断:
你的目标是"理解框架背后意味着什么",那以下几块是地基,值得按顺序了解:
前端框架不是"画 UI 的工具",而是一套替你回答'状态住哪、代码怎么分、逻辑在哪跑'的架构主张。UI 和速度只是这套主张的外在表现。当你用"三层 + 三个问题"去拆解任何一个框架,选型就从品牌偏好变成了有据可依的工程判断——这正是从"工具使用者"走向"系统构建者"的那一步。