01｜这一次真正变的，不是语法，而是网页对“像应用一样工作”的野心
前面四篇一路讲下来，主线大体还都停在“语言自身如何活下来”。
第一篇讲仓促出生。
第二篇讲浏览器大战里的分裂。
第三篇讲标准化先来止血。
第四篇讲 ES4 为什么在现代化路线上差点把整门语言谈崩。
可到第五篇，戏的重心要变了。
因为从这里开始，真正把 JavaScript 推上更高位置的，已经不只是委员会内部如何讨论未来。
而是：
Web 自己想变了。
它不再满足于“用户点一下，服务器回整页，浏览器整页刷新，再重新看一遍”这种旧节奏。
它开始想要另一种体验：
- 更即时
- 更连续
- 更像桌面软件
- 更像一整个会持续运行的界面
这件事最值得记住的地方，不是某一个技术名字。
而是它把 Web 的主问题改了。
以前大家问的是：
“网页能不能多一点交互？”
到这一步，问题已经慢慢变成：
“网页能不能像应用一样持续工作？”
而一旦问题变成这样，JavaScript 的位置就会立刻变。
它不再只是页面角落里的补丁工。
它会被硬推到更中心的地方。
02｜Ajax 真正重要的，不是这个词，而是它替整个行业把一种新体验命了名
今天大家提 Ajax，很容易有两种反应。
一种是老前端会觉得亲切。
另一种是新一点的开发者会觉得这个词已经有点年代感。
这都正常。
因为 Ajax 本来就不是某个单一技术产品。
Jesse James Garrett 当年那篇文章开门见山就说得很清楚：
Ajax isn't a technology.
它是一组已经存在的东西，在某个时间点上，被突然看成了一个整体：
- XHTML / CSS
- DOM
XMLHttpRequest- JavaScript
- 再加上一整套“别整页重载”的交互思路
这话看上去很普通。
可它真正厉害的地方在于：
它替整个行业把一种已经开始冒头、但还没完全说清楚的新体验命了名。
命名这件事在技术史里特别重要。
因为很多趋势在被命名前，往往只是零散现象。
一旦被命名，它就变成方向。
Ajax 也是这样。
在 Jesse 那篇 2005-02-18 的文章里，Google Suggest 和 Google Maps 被摆成那种新体验的代表。
文章里那句更值得记：
a fundamental shift in what's possible on the Web
这不是夸张修辞。
它其实非常准确地抓住了当时那种突然改道的感觉：
Web 没有换掉浏览器。
也没有换掉 HTML。
可用户对它的期待，已经开始不再像看网页。
而越来越像在用一个持续运行的界面系统。
03｜真正把这件事做出冲击力的，不是概念，而是 Gmail 和 Google Maps 那种“居然可以这样”的现场
技术概念本身不会吓到行业。
真正吓到行业的，永远是体验现场。
这就是为什么 Gmail 和 Google Maps 会变成这条线上的标志物。
Gmail 在 2004-04-01 公开预览时，Google 官方宣传的卖点之一当然是搜索和超大容量。
可它真正让人突然意识到“事情不一样了”的，不只是邮箱能存更多。
而是它的交互感受开始明显脱离旧式网页：
- 你不再每动一下都像跳到新页面
- 界面状态可以持续保留
- 某些操作开始显得更即时
接着到 2005 年的 Google Maps，这件事就更明显了。
因为地图这种东西特别适合暴露旧 Web 的笨重：
如果每拖一次地图都整页刷新，你立刻就会感觉整套体验像石头做的。
可一旦页面能局部更新，拖动、平移、再加载周边内容，整个感觉就完全变了。
它会让用户第一次明确意识到：
浏览器里的页面，不一定非得每次都像一张重新印刷的新海报。
它也可以像一个一直活着、一直响应、一直局部变化的界面。
这才是 Ajax 真正炸开的地方。
不是行业突然发现了某个新 API。
而是行业突然看到：
原来 Web 真能往“应用”这边跨。
04｜而这一切的底层节奏变化，最后都压到了 JavaScript 身上
这里最关键的一步，是很多人后来容易忽略的。
他们会觉得：
“那不就是 XMLHttpRequest 很重要吗？”
当然，XMLHttpRequest 很重要。
但它的重要，不在于它单独有多神奇。
而在于：
一旦页面不再靠整页跳转推进，浏览器里就必须有某样东西负责持续接管状态、事件、局部更新和异步请求之间的节奏。
这个东西是谁？
只能是 JavaScript。
因为 HTML 不负责调度。
CSS 不负责协调异步行为。
浏览器虽然给你对象和接口，但真正把这些东西绑成可工作的交互过程的人，最终还是脚本。
所以 Ajax 时代真正抬升的，不只是某个 API 的地位。
它真正抬升的是 JavaScript 的职责。
从这时候开始，JavaScript 不再只是：
- 写点表单校验
- 做点按钮响应
- 给页面加一点小动作
它开始越来越像：
- 状态协调器
- 交互调度器
- 页面局部更新的发动机
- 浏览器和服务器之间持续通信的胶水层
也就是说，第五篇最想立住的一句，其实是：
Ajax 不是让 JavaScript 多了一项技能，而是让整个 Web 突然开始把更多关键工作都压给它。
05｜XMLHttpRequest 这条线最有意思的地方，是它先不是标准英雄，而是微软世界里一个有点别扭的前史
这里还得把 XMLHttpRequest 单独拿出来看一下。
因为很多人今天回头谈 Ajax，容易把它想成：
“浏览器某天终于正式提供了一个异步请求接口，然后世界就变了。”
真实历史没有这么整齐。
更接近现实的是：
这条能力先是在微软那边以一个有点歪、有点别扭、也不太像公共标准的形态冒出来。
早期它和 MSXML、ActiveX 那些东西连得很紧。
一开始甚至不是今天大家熟悉的那个统一构造器姿势。
这很典型。
很多后来改变 Web 的能力，最早都不是作为干净的公共标准横空出世。
它们往往先以某种：
- 厂商路线
- 实用补丁
- 有点丑但真能用的方式
在现实里活下来。
XMLHttpRequest 就是这样。
这也解释了为什么 Ajax 从一开始就带着很重的现实主义。
它不是“标准组织先设计好了一个纯净未来”。
它更像：
大家先从能用的东西里拼出一种新体验，再回头给这套活法起名、解释、扩散。
这一点和前面几篇其实一脉相承。
Web 很多关键跃迁都不是先有图纸再有现实。
更常见的顺序是：
现实先跑起来，语言和标准再追着补秩序。
06｜这时候库之所以突然变重要，不是因为开发者爱堆抽象，而是因为现实太脏
一旦 Web 开始往应用方向走，另一个老问题也会立刻被放大：
浏览器现实依然不干净。
这就导致一个特别要命的局面。
你明明已经看到新体验的方向了。
可你真想把它做出来时，又会马上撞上：
- 浏览器差异
- DOM 操作别扭
- 异步请求写起来麻烦
- 事件处理到处是坑
这时库为什么会崛起，就很好理解了。
不是因为开发者忽然集体爱上封装。
而是因为：
当一套新体验已经被市场证明有价值，但平台底层又还不够顺手时，中间层就一定会长出来。
所以 Prototype 在 2005 前后会冒头，特别合理。
它官网后来那句自我描述就很说明问题：
smooths over the rough edges of cross-browser development
翻成人话就是：
浏览器世界太糙了，我来帮你磨平一点。
而 jQuery 到 2006 年之后的爆发，更是把这件事推到极致。
它为什么会火成那个样子？
因为它抓住的不是某个抽象理想。
它抓住的是一代开发者最具体的痛：
- DOM 太难用
- 事件太烦
- Ajax 太别扭
- 跨浏览器太累
所以第五篇里写库，不该写成“生态突然繁荣”。
更准确的说法是：
平台现实不够干净，于是库成了开发者通往新体验时代的临时基础设施。
07｜也就是说，Ajax 真正改写的不是“能不能异步”，而是 Web 的默认叙事
这一步特别重要。
因为如果只把 Ajax 理解成“浏览器可以异步拉数据”，你会低估它。
它真正改写的，其实是整个 Web 的默认叙事。
在它之前，浏览器页面的默认节奏更像：
- 用户动作
- 浏览器发请求
- 服务器回整页
- 页面重来一遍
在它之后，越来越多人开始把 Web 想成：
- 页面先活着
- 状态持续留着
- 局部区域不断变
- 请求和响应在后台穿梭
- 用户不一定每次都感知到“页面切换”
这差别特别大。
因为它意味着，Web 从“页面集合”的气质，开始向“会话中的应用界面”靠近。
而一旦默认叙事改了，开发者对 JavaScript 的期待也会跟着改。
以前期待它：
- 添点行为
- 修点小毛病
后来期待它：
- 管状态
- 管异步
- 管局部刷新
- 管交互连贯性
这等于把 JavaScript 从边角功能，直接推向了体验主轴。
从这里开始，后面很多你今天觉得理所当然的前端现实，其实都已经埋下了根：
- 更重的客户端逻辑
- 更复杂的框架需求
- 更明显的工程化压力
换句话说，Ajax 不是现代前端复杂度的全部起点，
但它绝对是其中最关键的一次加速。
08｜为什么 Ajax 真正抬起来的，不只是网页体验，而是 JavaScript 的地位
把前面这些线叠一起看，第五篇最重要的判断其实可以压成一句：
JavaScript 不是突然更强了，而是 Web 突然更依赖它了。
这句话特别重要。
因为很多人后来会误会：
好像是 JavaScript 自己一路升级、一路扩张，最后主动抢到了今天的位置。
事情当然没那么简单。
更接近真实的过程其实是：
- Web 想变得更像应用
- 用户开始期待更连续的界面体验
- 浏览器开始暴露更多可用能力
- 开发者开始用库和技巧把这些能力拼起来
- 最后所有这些压力，一起把 JavaScript 推到中心位置
也就是说，JavaScript 在这里并不是唯一主角。
它更像那个：
被 Web 平台整体升级需求硬推到主舞台的人。
而一旦它被推上去，后面的故事就不会再回头了。
因为从这之后，你已经很难再把 JavaScript 仅仅理解成“网页脚本”。
它开始越来越像：
浏览器里那套应用逻辑真正的执行层。
09｜这也就是为什么下一篇必须谈性能：当 Web 真想像应用，大家很快就会开始嫌 JavaScript 不够快
第五篇如果只讲到这里，其实还不完整。
因为一旦 JavaScript 被推成应用引擎，一个下一阶段的问题会立刻冒出来：
那它跑得够不够快？
这几乎是必然的。
你让它多做一点小动作时，性能问题还没那么刺眼。
可你一旦让它开始承担：
- 更复杂的界面逻辑
- 更频繁的 DOM 更新
- 更持续的交互节奏
- 更像应用的客户端状态处理
用户就会马上感知到卡顿、迟钝、响应慢。
也就是说，Ajax 时代的成功，实际上替下一篇把战场铺好了。
它先把 JavaScript 推到更高责任位。
接下来，浏览器厂商就必须回答：
既然 Web 真的想往应用走，你们到底打不打算认真把这门语言跑快。
这也就是为什么第五篇结尾，最自然要接到第六篇：
V8、JIT、Chrome 和整轮引擎性能战争，根本不是突然发生的。
它们是 Ajax 时代把 Web 应用化以后，必然爆出来的下一场大戏。
10｜Ajax 真正改写的，是浏览器页面的身份
Ajax 最值得记住的，不是它把几种旧技术拼在一起取了个新名字。
更值得记住的是：
它第一次让整个行业大规模相信：浏览器里的页面，不一定只是文档，也可以是持续运行的应用界面。
而一旦这个信念成立，JavaScript 的位置就再也回不去了。
所以第五篇如果只记一句，就记这句：
Ajax 不是让 JavaScript 多了一点异步能力，而是让整个 Web 开始把“像应用一样活着”这件事，越来越多地压到 JavaScript 身上。
编者注（事实核对）：文中关于 Ajax 的命名与定义，主要依据 Jesse James Garrett 于 2005-02-18 发表的 Ajax: A New Approach to Web Applications；其中 “Ajax isn't a technology” 与 “a fundamental shift in what's possible on the Web” 均来自原文。关于 Gmail 与 Google Maps 作为 Web 应用化代表节点的叙述，依据 Google 当年的官方新闻与博客归档互证。关于 XMLHttpRequest 的早期微软背景，依据 Microsoft 旧文档与后续标准资料整理。关于 Prototype 与 jQuery 的角色，正文将其概括为“磨平浏览器粗糙现实的临时基础设施”，属基于当时库定位与行业语境的写作性总结。
关键人物速览
- Jesse James Garrett：
Ajax这个名字的命名者。第五篇里他最重要的作用，不是发明技术，而是替一种已经开始改变 Web 的体验命了名。 - Sam Stephenson：
Prototype的作者。理解为什么库会在Ajax时代迅速变成开发者现实工具，他是关键人物之一。 - John Resig：
jQuery的创造者。第五篇里他代表的是另一种更大规模的现实：一代开发者需要一把更顺手的跨浏览器前端工具。
参考与延伸阅读
Ajax: A New Approach to Web Applications
https://hotway.s3.us-east-1.amazonaws.com/ajax/Ajax%20-%20A%20New%20Approach%20to%20Web%20Applications.pdfGmail 发布公告（Google, 2004）
http://googlepress.blogspot.com/2004/04/google-gets-message-launches-gmail.htmlGoogle Maps 发布博文（Google Blog, 2005）
http://googleblog.blogspot.com/2005/02/on-map.htmlGoogle Maps and Keyhole Integration（Google, 2005）
https://googlepress.blogspot.com/2005/04/google-maps-and-keyhole-integration_03.htmlPrototype JavaScript framework
http://prototypejs.org/jQuery History
https://jquery.com/history/Ten Years of jQuery and Beyond
https://blog.jquery.com/2016/01/14/ten-years-of-jquery-and-beyond/XMLHttpRequest Standard
https://xhr.spec.whatwg.org/
下篇预告：V8、JIT 和 Chrome，为什么让 JavaScript 从能用变成必须认真对待。