刚把《Ajax修炼之道》拆封，我连翻两页，心里就盘算着给书架腾地儿。现在市面上Web开发的书，十本倒有八本干同一件事：把API和语法往死里码。排得跟新华字典似的，看着就脑仁嗡嗡的。这本Pragmatic系列的小册子倒挺识相。没整那些虚头巴脑的理论，直接把异步交互那点事儿像拆老式收音机一样，连螺丝钉都给你摆得明明白白。小白？老油条？不管你是刚敲下第一行console.log()的小白，还是以前靠全页刷新混日子的老油条，翻开它，保准能咂摸出点新滋味。
最戳我的，是作者怎么跟“复杂”这俩字死磕。大伙儿一提起Ajax，脑子里准是XMLHttpRequest、回调地狱、跨域报错连环套。听着就头大。是吧？人家偏不。愣是从DHTML和DOM操作这种老掉牙的东西起头，一步步把那些看着唬人的Web 2.0特效，扒成了最实在的代码拼接。读到这儿，我脸有点热。以前写页面，我总犯轴，非得等服务器把整页数据嚼碎了吐回来，才觉得这事儿办妥了。书里原话写得特实在：“编写形式生动的应用程序并不困难，Google Map也并非什么尖端技术……但人们却对它充满敬畏。”刚看觉得是句正确的废话。后劲儿挺大。技术哪有什么高不可攀的魔法？不过是我们自己先把它供上了神坛。你把异步请求当成一根随时能拔能插的电话线，别管它多炫酷的动效，剥开外壳，全是顺着逻辑往下走的寻常事。这事儿，大概就是这么个意思。
作者没让前端在那儿单打独斗。镜头一转，直接怼到了服务器端。PHP、Ruby on Rails、Java、.NET，这些以前各立山头、互相看不顺眼的后端语言，在Ajax这套玩法里被硬生生缝到了一起。我以前老觉得，前端就是负责涂脂抹粉，后端负责搭骨架子，中间隔着HTTP协议，老死不相往来。书里给出的法子可灵活多了。前端只管伸手要那块肉，后端负责精准投喂。这招“按需分配”放理想项目里确实管用。但放在现实里呢？未必那么顺滑。咱们平时接活儿，总爱把一堆烂摊子捆成个死结，憋三个月交个大家伙，累得半死还容易翻车。要是真能拆成一块块能独立跑的小模块，随时对个进度，那倒是好事儿。不过嘛，跟产品扯皮、跟老板催进度的时候，谁又真能按这个节奏来呢？书里的理想很丰满。落地时，多半得挨几轮现实毒打。
翻到后半截，作者开始扒怎么调回调、怎么顺着源码找bug，顺手甩出一长串主流工具包。说实话，刚看到这堆名单我直皱眉，太像说明书了，密密麻麻的。但作者收得很稳，没趁机带货。他意思很明白：别一上来就抄现成的轮子，自己先拿扳手拧两圈螺丝。想当年我学东西，总想走捷径，代码还没读明白就急着搬框架，结果碰上一个兼容性坑，硬是卡了整整两天，头发都薅掉一把。后来老老实实摸清了XMLHttpRequest的脾气，再瞅那些封装好的库，才明白人家也就是把日常动作捆了个方便携带的包裹。我觉得吧，想抄近道？往往绕得最远。
书合上，我对“响应”俩字有了点不一样的体感。Ajax折腾半天，图的不光是页面不刷新那点痛快，更是把用户的时间当回事。它逼着咱们把干等的空档切碎，把反馈的节奏提上来。现在的产品里，到底还有多少地儿在逼着用户死盯那个转圈圈？我上周用个打车软件，叫车页面卡了半分钟，那个转圈看得我血压飙升。下次敲代码或者盘项目的时候，不如自个儿拷问一句：我搞出来的这玩意儿，是让用户干等着世界重启，还是让他们想走就走，想回随时能接着唠？
框架换了一茬又一茬，底层逻辑早就改了好几轮。但那种让网页“轻盈地呼吸”的脾气，估计得在代码里赖着不走了。毕竟，谁愿意天天跟卡顿较劲呢？对吧？