今天你随便打开一个认真一点的前端项目，十有八九都会默认看到这些东西：
- 组件目录
- 路由目录
- 状态管理或数据获取约定
- 官方推荐脚手架
TypeScript- SSR / SSG / hydration 一类词
很多时候，我们甚至已经不太把这件事当回事。
可如果你退一步看，就会发现这件事其实非常奇怪：
为什么前端最后会走到一种几乎默认需要“先选框架，才能开始认真写应用”的现实？
为什么同样是在浏览器里写界面，
一开始大家只觉得要有个 jQuery 就差不多了，
后来却又非得经历：
BackboneKnockoutEmberAngularJSReactVueSvelteSignals
这一连串路线之争？
为什么这些框架表面上都在说“让开发更简单”，
底下却往往都在争更深的一件事：
到底谁有资格定义前端应用该怎样被组织。
这套 《框架江湖》，想讲的就是这些事。
它不是框架教程。
也不是“十分钟看懂 React / Vue / Angular 区别”的速食对比文。
它更像一部夺权史。
一种特别典型的前端夺权史：
Web 一旦从文档系统变成应用平台，前端就不再只需要更顺手的 DOM 工具。它开始需要新的秩序来解释页面结构、状态流动、组件边界和默认工作流。于是每一代框架看起来像在提供更好的开发体验，实际上却都在重新分配前端世界里的权力。
你可以先把这套系列记成六幕：
jQuery这类库先统一了浏览器现实，但它们没有统一应用结构。- 浏览器一旦开始像应用，
Backbone、Knockout、Ember、AngularJS就会争着来给前端立规矩。 React最后改写的，不只是一个框架市场，而是整套 UI 的思考方式。Vue的突围，不只是“更友好”，而是它把采纳成本和治理摩擦压得更低。Svelte、Signals、细粒度响应式的重新流行，说明 React 时代的默认重量又开始被系统性质疑。- 到今天，框架已经不只是 UI 工具，而越来越像现代前端的默认治理层。
这六幕一连起来，你就会发现，这套系列真正想讲的，不是“哪家框架后来更火”。
而是另一件更大的事：
前端框架史不是自然进步，也不是一条谁技术更先进谁就稳赢的直线。它更像浏览器端复杂度不断升级之后，前端社区一轮轮围绕组织权、状态权、组件边界和默认入口打出来的长期制度战争。
这套系列讲什么
我想讲的，不只是“AngularJS、React、Vue、Svelte 分别是什么”。
更想讲的是底下那几场反复重演的冲突：
- 为什么
jQuery明明已经非常成功，后来却还是不够 - 为什么
Backbone、Knockout、Ember、AngularJS会在差不多同一个时代集中爆发 - 为什么
React会把“页面怎么组织”改写成“状态怎么渲染” - 为什么
Vue的扩张路线看起来更温和，却同样能拿到主流秩序位置 - 为什么
Svelte、Signals这些路线会重新把“运行时到底该背多少锅”打成新争议 - 为什么今天很多团队在“选框架”时，实际已经是在选一整套默认工程现实
换句话说，这是一套关于 前端应用组织史、UI 心智变迁、复杂度分配方式，以及现代前端默认治理层如何形成 的系列文章。
这套系列真正要追的，不是框架名单，是谁在定义前端应用
如果你退一步看，会发现前端框架这些年的很多争论，表面上主角不同，底下其实一直在争几件更硬的事。
01｜到底谁有资格定义“一个前端应用”
最早的时候，这个问题没那么尖锐。
因为那时的网页更像文档，
前端代码也更像补丁。
有一点 DOM 操作，
有一点事件响应，
再加一点 Ajax，
很多事情靠库、插件和经验就能勉强撑住。
可一旦浏览器端开始承受这些东西，事情就变了：
- 页面状态越来越多
- 局部更新越来越频繁
- 用户交互越来越像桌面软件
- 代码之间的依赖和耦合越来越深
这时候麻烦就不再只是：
“怎么把某个按钮点了以后改一段 DOM。”
而会变成：
“整个前端应用到底应该怎么组织，才不会几个月后谁都不敢动。”
于是框架真正争的第一层，其实就是：
谁有资格给前端世界定义一份更像宪法的默认结构。
02｜复杂度到底该压给模板、组件、运行时，还是编译器
这条线特别关键。
因为框架之间最深的分歧，常常并不是功能多寡。
而是：
同一份复杂度，最后该被安排到哪一层。
有的路线会觉得：
- 模板应该更强
- 声明式绑定应该更强
- 框架应该替你多做决定
有的路线会觉得：
- 组件才是核心单位
- 单向数据流更稳
- 视图可以完全看成状态的投影
再到后面，又会有人反过来追问：
- 运行时是不是背太多了
- Virtual DOM 到底是不是必要成本
- 编译器或细粒度依赖跟踪能不能更早把复杂度消化掉
所以这套系列会反复追问：
框架每一次“更先进”的表象底下，本质上到底是在把复杂度重新分配给谁。
03｜开发体验之争，最后为什么会变成组织成本之争
很多人谈框架的时候，最先想到的是：
- API 顺不顺
- 写起来爽不爽
- 文档好不好
- 生态全不全
这些当然重要。
但如果只停在这里，还是会把框架史写浅。
因为现实世界里，团队最后选框架，往往不只是因为某个语法更优雅。
更常见的是这些问题：
- 新人能不能快速接手
- 大团队能不能形成统一约定
- 迁移成本高不高
- 默认工具链稳不稳
- 官方推荐路径清不清楚
也就是说，框架之争最后常常会从“开发体验之争”，慢慢变成：
谁能更低成本地接管团队的日常组织方式。
这也是为什么后来：
Vue的“渐进式”会特别重要React的生态与脚手架会越来越关键Angular的官方全套秩序会让它在企业里始终有位置
因为这时候框架已经不只是技术选项。
它也开始像一种治理方案。
04｜默认入口为什么比单个 API 更有权力
这是今天特别值得盯住的一层。
因为现代前端世界里，真正最有权力的东西，
往往不是某个单独 API。
而是：
- 新项目默认怎么起
- 目录默认怎么分
- 路由默认怎么接
- SSR 默认怎么做
TypeScript默认怎么配- 数据获取默认怎么推荐
一旦这些默认值被框架和官方生态拿住，
框架就不再只是“你渲染 UI 的一个库”。
它会越来越像：
现代前端世界的默认入口。
所以这套系列里还会一直盯着一个问题：
今天框架真正掌握的，到底是不是“渲染能力”，还是“默认现实”的定义权。
05｜为什么框架总是一边解决问题，一边生成新问题
这是框架史最典型、也最前端的一点。
每一代框架几乎都真的解决了上一代的某种痛。
但同时，它也几乎都会制造出新的重：
- 新心智负担
- 新迁移成本
- 新生态绑定
- 新脚手架依赖
- 新运行时或编译时复杂度
所以框架史不是一条线性升级史。
它更像一轮轮压力转移：
旧复杂度被新框架收编后，复杂度并没有消失，而是换了一个名字、换了一层位置、换了一套默认值继续活下去。
这也是为什么框架世界永远不会真的停火。
因为每一代胜利，本身都会制造下一代反攻的理由。
为什么这条线特别值得单独拆出来
因为它几乎解释了今天前端开发者日常里很多最强的体感。
你今天感觉“前端一上来就得选框架”，往往不是因为大家突然都更爱折腾。
而是因为背后已经默认连着一整套现实：
- 页面不再只是页面
- 状态不再只是几个变量
- 路由不再只是跳转
- 组件不再只是复用片段
- 构建链不再只是打包
- 团队协作不再只是代码风格问题
这些要求单看都合理。
可它们叠起来，就会自然逼出一整套新的问题：
谁来给这份复杂度安排边界，谁来给团队提供默认秩序。
所以框架江湖真正值得写的，不是“哪些框架后来流行”。
而是：
为什么当 Web 应用化把复杂度越来越深地压到浏览器端之后，前端社区会一轮轮把页面解释权、状态解释权、组件解释权和工作流解释权交给新的框架秩序。
这套系列准备怎么写
目前我更倾向于按六篇主线来写：
库为什么先起来，框架为什么后来才必须起来：因为统一浏览器现实，不等于统一应用结构
先讲Prototype、jQuery、插件文化和库时代的上限。浏览器像应用之后，MVC / MVVM 为什么突然都冒出来了：因为前端第一次大规模需要“宪法级结构”
讲Backbone、Knockout、Ember、AngularJS分别想规训什么。React为什么改写了 UI 心智：因为它真正赢下的不是一个库位，而是“状态驱动渲染”的解释权
讲组件、单向数据流、JSX、Virtual DOM 和反模板路线。Vue为什么能突围：因为它把现代框架能力和渐进采纳路径压到了更低摩擦的平衡点
讲 Evan You 的路线、渐进式、Vue 3、默认化进程。Svelte、Signals为什么会重新打开运行时战争：因为 React 时代的默认重量开始被系统性质疑
讲编译时、细粒度响应式、Signals 传播和“复杂度该压给谁”。框架为什么从可选 UI 工具，长成了现代前端默认治理层：因为今天大家选的已经不是单个渲染库，而是一整套默认现实
讲 CLI、路由、SSR、类型、文档与 meta-framework 入口。
也就是说，这套系列想讲的，不只是“框架换代”。
更想讲：
为什么前端框架最后没有停在“做页面更方便”的层面，而是一步步长成了现代前端世界里最能定义默认工作流和默认协作秩序的力量。
先记住这句
如果你现在只想先记住一句话，那就记这句：
前端框架史不是自然进步，而是 Web 应用复杂度不断升级之后，前端社区一轮轮围绕“页面该怎么组织、状态该怎么流动、复杂度该压给谁、团队该怎样默认开工”打出来的长期制度战争。
而且这场战争最特别的地方还在于：
它没有一个简单干净的终点。
jQuery 没有白来。
AngularJS 没有白做。
React 没有终结一切。
Vue 也没有让问题彻底消失。
Svelte 和 Signals 的重新上升，更说明这场仗还远没打完。
这就是前端框架最典型的历史节奏。
不是一代框架彻底消灭另一代。
而是：
旧问题刚被收编成默认值，新问题立刻又会从下一层把秩序重新打松。
先记住：框架打到最后，争的是现代前端的治理权
所以这套 《框架江湖》 真正想讲的，不是“哪个框架更值得学”。
更想讲的是：
为什么当前端终于重到不能只靠库、插件和工程默契维持时，谁来定义页面结构、状态流动、组件边界和默认工作流，便成了现代前端最重要的一场长期内战。
如果把 JavaScript 江湖 写的是行为层如何一路被推成 Web 平台中心，
把 模块化江湖 写的是代码组织方式如何打成长期制度战争，
把 前端工程化江湖 写的是写页面这件事如何被逼成一整套工程机器，
把 TypeScript 江湖 写的是一个并非官方正统的类型系统如何慢慢接管默认现实，
那 框架江湖 要写的，就是：
当这些历史压力一起压到浏览器应用身上之后，前端社区如何一轮轮把“应用该怎样存在”这件事，交给新的框架秩序来解释。
关键人物速览
- John Resig：
jQuery的核心发起者。理解为什么前端最先需要的是“更好用的库”，绕不开他。 - Jeremy Ashkenas：
Backbone的发起者。理解最小结构主义为什么会在浏览器应用早期有强吸引力，绕不开他。 - Miško Hevery：
AngularJS的核心人物之一。理解双向绑定、模板与大框架式治理为什么一度极具号召力，绕不开他。 - Yehuda Katz / Tom Dale：
Ember的关键人物。理解“约定优于配置”的完整框架野心，绕不开他们。 - Jordan Walke / Pete Hunt：
React路线的重要代表。理解为什么 UI 会被重新解释成状态驱动渲染，绕不开这条线。 - Evan You：
Vue的发起者。理解“渐进式”为什么不只是宣传语，而是一种现实世界的扩张策略，绕不开他。 - Rich Harris：
Svelte的核心发起者。理解编译时反攻和对 Virtual DOM 叙事的公开反击，绕不开他。
参考与延伸阅读
Ajax: A New Approach to Web Applications
https://adaptivepath.org/ideas/ajax-new-approach-web-applications/Announcing the jQuery Blog | Official jQuery Blog
https://blog.jquery.com/2006/01/24/jquery-blog/Backbone.js
https://backbonejs.org/Knockout : Introduction
https://knockoutjs.com/documentation/introduction.htmlEmber 1.0 Released
https://blog.emberjs.com/ember-1-0-released/Why did we build React?
https://legacy.reactjs.org/blog/2013/06/05/why-react.htmlVue 3 as the New Default
https://blog.vuejs.org/posts/vue-3-as-the-new-default.htmlSvelte 3: Rethinking reactivity
https://svelte.dev/blog/svelte-3-rethinking-reactivitySignals | Preact Guide
https://preactjs.com/guide/v10/signals