1.1 从刀耕火种到工程化：框架的演进与重要性

1.1 从刀耕火种到工程化：框架的演进与重要性

本节摘要：前端开发经历了从"直接操作 DOM 的手工艺"到"工程化框架体系"的演进。本节以 jQuery、AngularJS、React 三个里程碑为主线，讲清每一次范式转换解决的核心痛点，并说明为什么今天的前端项目几乎绕不开框架。理解这段历史，你就不会把框架当成"库的合集"，而会把它看作前端行业对效率、可维护性与性能问题的集体回答。

学习目标

阅读完本节，你应当能够：

1. 列举原生 DOM 开发模式在效率、可维护性、协作与性能上的四大痛点。
2. 说出 jQuery 为什么能成为事实标准，以及它为什么"只是库不是框架"。
3. 解释 AngularJS 如何让前端从"库时代"跨入"框架时代"。
4. 说明 React 的声明式 UI 与虚拟 DOM 解决了什么问题。
5. 用一段话总结框架对团队协作与复杂应用构建的价值。

一、问题与直觉：一个页面里塞了三千行脚本之后

先看一个没框架的早晨。你要做一个带搜索、筛选、翻页、排序的表格页，用原生 JavaScript 写。搜索框输入一次，你得手动找到表格元素、遍历行、比对关键字、逐行显隐；排序要重排 DOM；分页要重算、再重绘。写的时候一时爽，改需求的时候你恨不得把浏览器摔了——改一处显示逻辑，常常要顺着事件绑定的链条追出七八个函数。

早期 Web 开发就是这副样子。项目小的时候尚能忍受，一旦交互复杂起来，四个问题会同时爆发：

• 开发效率低：大量重复的 DOM 操作，同样的增删改查逻辑换个页面再来一遍。
• 可维护性差：全局变量泛滥、命名冲突、逻辑耦合，一个人写的代码另一个人看不懂也不敢动。
• 协作困难：没有统一的代码结构，多个人改同一块逻辑时集成是噩梦。
• 性能与兼容性瓶颈：手动优化渲染流程既难又易错；不同浏览器对同一段标准 API 的支持参差不齐。

💡 关键直觉：框架本质上是"把行业踩过的坑打包成约定"——你不需要重复发明轮子，只需要按它的规则摆积木。

二、核心原理：三个里程碑，三次范式转换

2.1 jQuery：把 DOM 操作从地狱拉回人间

2006 年前后，jQuery 用一句话改变了前端："让开发者专注业务，不关心浏览器差异。" 它以简洁的 API 和强大的选择器简化了 DOM 操作与事件处理，迅速成为事实标准。注意，jQuery 解决的问题是"操作 DOM 更爽"，但它没有回答"UI 如何随数据自动更新"——数据变了，你还是要手动去改 DOM。所以它是库：你在调用它，控制权在你手里。

2.2 AngularJS：前端第一次有了"框架"的样子

2010 年 Google 发布 AngularJS，它引入了双向数据绑定、依赖注入、指令等概念。数据一变，视图自动跟着变——你不再需要手动同步 DOM，框架接管了这件事。这是"库"与"框架"的分水岭：控制权开始从开发者手里向框架转移。AngularJS 的出现标志着前端开发从"库时代"迈入"框架时代"。

2.3 React：用虚拟 DOM 重新定义渲染性能

2013 年 Facebook 发布 React。它的贡献不是"自动同步"——AngularJS 已经做过——而是把同步这件事做得更可控、更高效。React 坚持单向数据流：数据从父到子单向流动，状态变化触发重新渲染。配合虚拟 DOM：先在内存里构建一棵轻量对象树，用 diff 算法找出最小差异，再一次性批量更新真实 DOM。这让"声明式 UI"成为可能——你只需要描述"UI 在给定状态下应该长什么样"，React 负责把差异落到浏览器上。

Vue.js 于 2014 年由尤雨溪推出，走了第三条路：渐进式。它把 AngularJS 的双向绑定与 React 的组件化融合，但强调"按需引入、逐步改造"，你可以先在老项目里用它管一个小模块，再慢慢铺开。三种方案至今并行，恰好说明"让 UI 与数据同步"这件事没有唯一解。

2.4 为什么今天绕不开框架

框架的价值在项目变大时呈指数放大，而不是线性。组件化让代码可复用、可测试；模块化与数据流管理降低耦合；虚拟 DOM 与增量渲染提供性能基线；统一的开发范式让新人能更快接手、不同模块更好集成。更关键的是：没有框架，复杂交互与实时更新应用几乎无法靠人力维护——这正是原生开发模式在规模面前的极限。

2.5 兼容性问题的演进：从手写补丁到标准渐进

早期前端的一个隐性成本是跨浏览器兼容。同一段 API，IE 和 Firefox 的表现可能完全不一样，开发者被迫写大量分支判断或引入 polyfill。jQuery 当年的杀手锏之一，就是替开发者统一了这些差异。到了框架时代，这个问题换了打法：框架不再追求"抹平一切"，而是依赖现代浏览器标准，并通过编译工具（Babel）把新语法转译成目标浏览器能跑的版本。这意味着你今天用框架写代码，实际上同时拿到了三样东西：新语法的新特性、旧浏览器的兜底转译、以及不断收敛的标准差异。理解这一点，你就能解释为什么"框架包体积"这个话题会反复出现——那些转译与运行时逻辑，都是要随代码一起下载的。

2.6 生态的复利效应：为什么越大的框架越好用

框架的社区与生态存在明显的复利效应：使用者越多，第三方库越多；第三方库越多，新用户越愿意进来；越多人进来，问题被解决的速度越快，招聘越容易。React 的生态霸权很大程度上就是这样滚起来的。反过来，新技术框架即使技术上更先进，也常因为"生态不够"而在商业项目中被劝退。这条规律提醒我们：评估框架时，技术参数只是起点，"有多少人在用、多少人能修"往往比"功能强不强"更决定项目命运。第 3 章的社区维度会把这套逻辑量化，第 4 章的风险评估则告诉你它什么时候会反噬。

三、工程实践要点：什么时候该信框架，什么时候该存疑

框架不是万能药。选之前先给项目定位，避免"为了用框架而用框架"。

⚠️ 常见坑：把"项目用了框架"当成"项目质量有保证"。框架只是基础设施，代码质量取决于团队规范——这一点第 4 章会展开。

💡 关键直觉：判断一个框架值不值得学，先看它回答的是哪个时代的问题。能回答"下一个问题"的框架，才值得你长期押注。

3.1 演进视角下的技术选型三问

带着历史视角做选型，你会习惯性地问三个问题。第一问：这个框架解决的核心痛点，现在还存在吗？有些框架当年为了解决"浏览器差异"而生，如今标准收敛后价值已稀释。第二问：它的解决方案，有没有被后来的技术以更低成本实现？比如虚拟 DOM 的"计算换操作"思路，正被编译期优化等新路线挑战。第三问：它的下一个版本，回答的是什么问题？一个框架如果更新日志里全是周边功能，核心假设多年未动，那它可能已经进入了保守期。这三问比任何"技术对比表"都更能帮你预判一个框架的中期走势。

3.3 一个具体案例：从 jQuery 项目迁移到框架的决策复盘

假设你手上有一个五年前用 jQuery 写的后台系统，页面 200 个，交互正在越来越复杂，团队想迁移到现代框架。这个案例能演示演进史怎么指导决策。第一步，别急着"全量重写"，先盘点痛点：如果主要痛点是"状态同步混乱"，那迁移到 Vue/React 并引入响应式或单向数据流，收益最大；如果痛点只是"代码丑"，那换框架治标不治本。第二步，选择渐进路径：Vue 的渐进式特性允许你在 jQuery 页面上局部引入组件，慢慢替换，而不是一次推倒；这比"直接上 Angular 全家桶"的风险低一个量级。第三步，评估时间窗：如果系统还处在快速迭代期，迁移的机会成本高，不妨先冻结技术债，等业务稳定期再动。这个案例的启示是：演进史告诉我们"框架因问题而生"，所以迁移也必须"从问题出发"，而不是"从潮流出发"。

3.2 演进史给团队的三条实用建议

第一，迁移旧项目时，别用"新框架一定更好"掩盖"旧代码为什么不重构"的真实原因——很多遗留项目的病根不是框架旧，而是没有规范，换了框架病还在。第二，评估框架生命周期时，把"核心团队稳定性"和"赞助商"放进视野：大公司背书的框架（React 有 Meta、Angular 有 Google）通常抗风险能力更强，但也要警惕"公司战略调整导致项目冻结"的个案。第三，为团队定一条技术栈引入门槛：新框架必须经过 POC 验证、有明确收益点、且有人愿意做长期守护者，才允许进入生产项目——这条门槛能挡住一大半"因为新鲜所以想试"的冲动。第 4 章会把这些建议展开成可执行的流程。

要点速记

• 要点一：原生 DOM 开发在规模面前有四大痛点——效率、可维护性、协作、性能与兼容性。
• 要点二：jQuery 解决"操作 DOM 更爽"，是库；控制权在开发者手里。
• 要点三：AngularJS 引入双向数据绑定，控制权向框架转移，前端进入框架时代。
• 要点四：React 用单向数据流 + 虚拟 DOM 让声明式 UI 成为可能，重定义了渲染性能。
• 要点五：Vue 走渐进式路线，强调按需引入与逐步改造。
• 要点六：框架的价值随项目规模放大，但"上了框架"不等于"质量有保证"。

下一节我们把"框架"这个概念本身拆开：它和库的边界到底划在哪？这个问题看似抽象，实际直接决定你的选型思路。