01｜如果只看今天，你很容易误以为前端一开始就该有框架
今天很多人刚接触前端应用开发时，心里默认的起点已经是：
- 先选框架
- 再起脚手架
- 再按官方推荐的目录、路由、组件和数据获取方式往下走
所以很容易倒过来想象历史：
既然今天框架这么像前端默认入口，
那前端一路走过来，大概也是很早就需要框架的。
其实不是。
前端最开始最紧迫的问题，根本不是：
“整个应用该怎么组织？”
而是：
“这鬼东西到底怎么才能在不同浏览器里先写得动？”
这就是为什么框架史真正起手的主角，
并不是 React、Vue、AngularJS。
而是更早一层的那批库。
尤其是：
PrototypejQuery
它们先替前端世界做掉了一件特别关键的事：
把浏览器现实先勉强统一到了一个能正常开发的地步。
如果没有这一步，后面的框架大战很难这么快打起来。
因为在那之前，前端面对的首要敌人甚至不是应用复杂度。
而是浏览器自己。
02｜Ajax 之后，前端最先爆炸的不是架构问题，而是日常脏活
前面在 JavaScript 江湖 第五篇里已经讲过，
Ajax 真正改变的，不只是技术名词。
它改变的是整个 Web 的期待值。
网页开始不像一页一页翻的文档，
而越来越像一个持续运行的界面。
可一旦体验期待变了，麻烦也会跟着变。
开发者突然需要更频繁地处理这些事：
- DOM 查询和批量操作
- 事件绑定与移除
- 动画和效果
- Ajax 请求
- 浏览器差异
- 加载时机
这些问题单看都不高级。
也不浪漫。
可它们特别烦。
因为在那个阶段，前端最痛的往往不是“没有伟大架构理论”。
而是：
明明只是做个常见交互，结果要和 DOM、事件、浏览器差异缠半天。
所以最先起来的那批库，本质上不是来给前端设计宪法的。
它们更像：
来收拾战场的工兵。
jQuery 这条线特别典型。
John Resig 在 2006-01-24 的博客里写：
how badly Javascript programmers want a better library for writing code with
这句话非常值得记。
因为它一下子把当时的需求说透了。
开发者想要的，还不是整套框架秩序。
他们先想要的是：
一个更好写代码的库。
这是库时代最重要的现实判断。
03｜jQuery 赢下来的，不只是 API，而是一种“前端终于顺手了”的体感
今天回头看 jQuery，很多人容易把它理解成：
“哦，就是以前做 DOM 操作的库。”
这当然没错，
但还是太轻了。
jQuery 真正厉害的地方，不在于它抽象了几个常见方法。
而在于它让一整批前端开发者第一次感觉到：
浏览器里的 JavaScript，终于开始像一个能日常工作的开发环境。
你今天觉得这些事稀松平常：
$(...)$(document).ready(...)- 统一事件处理
- 链式调用
- Ajax 接口
可放在当时，它们构成的不是一个小优化。
而是一种工作感受的整体变化。
John Resig 在 2006-02-23 那篇 Bugs Squished, AJAX on the way! 里写得很直接：
- 各种显示隐藏细节在不同浏览器里被修平
document.ready()行为被统一- 一批浏览器特殊属性被自动纠偏
- Ajax 模块准备合并进核心
你如果仔细看，会发现这些都不是“伟大框架哲学”。
全是脏活。
可技术史里经常就是这样：
谁先把最烦的脏活做得足够顺，谁就先拿到现实世界的入口。
所以 jQuery 的胜利，首先不是组件哲学的胜利。
它是：
前端日常生产力的胜利。
04｜库统一了浏览器现实，却没有回答“应用怎么存在”
可也正因为如此，库时代很快就会撞到自己的天花板。
因为 jQuery 这类库最擅长解决的问题，是局部问题：
- 选元素
- 绑事件
- 发请求
- 改样式
- 做效果
可 Web 一旦越来越像应用，前端需要处理的就不再只是这些局部动作。
真正开始变难的是：
- 状态放在哪里
- 视图和数据怎么对应
- 多个区域怎么协同更新
- 路由怎么管理
- 代码边界怎么切
- 团队成员怎么在同一个项目里不互相踩爆
到这一步，麻烦的性质就变了。
它不再只是“这段 DOM 写起来烦”。
而会变成：
整个应用到底该靠什么结构活下去。
库在这里的局限就会越来越明显。
因为库本质上更像能力集合。
它能让你干活更快。
但它通常不太替你回答：
这份活应该怎么组织。
这也是为什么当年插件文化虽然繁荣，
却还是没法从根上解决前端应用复杂度。
插件当然可以越长越多。
但插件越多，另一种问题也会越来越重：
- 谁来约束它们之间的关系
- 谁来规定状态怎么流动
- 谁来解释“一个页面”之外的应用结构
库能解决“点状能力”。
框架才开始碰“整体秩序”。
05｜jQuery 时代最深的遗产，不是代码写法，而是把前端职责抬高了
这点特别关键。
很多人谈框架前史时，会把 jQuery 看成一种后来被淘汰的旧技术。
可如果这么看，就会漏掉它真正重要的历史位置。
jQuery 最大的遗产，不只是 API 形式。
而是它帮整个行业证明了一件事：
只要把浏览器现实先驯服到足够顺手，前端就会自然接手越来越多原本不属于它的复杂工作。
换句话说，
jQuery 不是把前端复杂度消灭了。
它反而在客观上加速了另一件事：
让更多复杂度更早、更自然地流进前端。
因为当 DOM、事件、Ajax 这些东西没那么痛了之后，
产品和团队不会说：
“太好了，那我们就停在这里吧。”
现实只会变成：
“既然现在做这些交互已经顺多了，那能不能再做更复杂一点？”
于是：
- 页面状态越来越多
- 局部交互越来越密
- 页面间切换越来越像应用路由
- 前端代码体量越来越大
而这一切，都会把问题继续往上推。
从库层，推向架构层。
06｜所以库时代真正留下来的问题是：大家终于能大规模干活了，但还没有一部宪法
把这条线拉清楚以后，你就会发现：
库时代并不是框架时代的反面。
它更像框架时代的前提。
因为如果连浏览器差异、DOM 操作、Ajax 交互这些基础脏活都还没被压平，
大家根本没有余裕去认真讨论更高层的秩序问题。
可一旦这些脏活被处理得差不多了，
另一个更难的问题就会浮上来：
一个越来越像应用的前端系统，到底该怎样被组织。
这时候，大家会开始越来越不满足于：
- 几个顺手方法
- 一堆插件
- 一些页面级脚本习惯
因为这些东西都太像“地方经验”。
而不是“共同秩序”。
于是前端世界很快就会进入下一阶段：
不是继续找更顺手的库，
而是开始找：
谁能给浏览器应用立规矩。
这就是 Backbone、Knockout、Ember、AngularJS 那批框架很快会集中冒出来的真正背景。
07｜库先把浏览器变顺手，框架才有资格争组织权
为什么今天还值得回头看这段库时代前史？
因为很多现代前端的基本气质，
其实就是在这个阶段先被养出来的。
比如：
- 前端特别看重“开发者体感”
- 先解决日常痛点，再谈更大秩序
- 生态插件繁荣会被视为强信号
- 大家天然相信“把一层复杂度收掉以后，业务会继续把更高层复杂度压进来”
而且直到今天，
很多框架的扩张方式，依然很像当年的 jQuery：
先让你觉得顺手，
再让你慢慢接受它的默认秩序。
所以这段历史真正值得记住的，不是：
“jQuery 曾经很火。”
而是：
库先把浏览器变成了一个足够可开发的现实，框架才有机会把战场从 DOM 操作，抬高到应用组织权。
下一篇要讲的，就是这场抬高之后的第一轮大爆发：
当浏览器开始越来越像应用，为什么 Backbone、Knockout、Ember、AngularJS 会突然都冲出来抢着立规矩。
参考与延伸阅读
Ajax: A New Approach to Web Applications
https://adaptivepath.org/ideas/ajax-new-approach-web-applications/Prototype JavaScript Framework: A foundation for ambitious web applications
https://prototypejs.org/Prototype JavaScript Framework | Download Prototype
https://prototypejs.org/download/Announcing the jQuery Blog | Official jQuery Blog
https://blog.jquery.com/2006/01/24/jquery-blog/Bugs Squished, AJAX on the way! | Official jQuery Blog
https://blog.jquery.com/2006/02/23/bugs-squished-ajax-on-the-way/AJAX new FX and more! | Official jQuery Blog
https://blog.jquery.com/2006/02/26/ajax-new-fx-and-more/jQuery 1.0 – Alpha Release | Official jQuery Blog
https://blog.jquery.com/2006/06/30/jquery-10-alpha-release/