John Resig 与 jQuery：塑造前端的库

为什么 jQuery 如此重要

2000 年中期构建网站是什么感觉

如果你在 2005–2008 年左右搭建网站，你并不仅仅是在“写 JavaScript”。你在和浏览器讨价还价。

一个简单的功能——高亮菜单项、显示模态框、验证表单、在不刷新整页的情况下加载一段 HTML——都可能变成一个小型的研究项目。你会查哪个方法在哪个浏览器中存在、哪个事件表现不同、为什么某个 DOM 调用在你的机器上能用却在一半的用户那里崩溃。

“一次编写，到处运行”的问题

开发者想要“写一次，到处运行”，但浏览器差异让它感觉像“写三次，到处测试”。Internet Explorer 有它自己的怪癖，旧版 Firefox 和 Safari 在一些边缘情况上意见不一，甚至像事件处理和 DOM 操作这样的基础也可能不一致。

这种不匹配不仅浪费时间——还改变了团队敢于构建的东西。交互式 UI 虽然可行，但代价是高昂且难以维护。许多站点因为要兼顾所有浏览器所需的成本太高而保持比应该更简单的状态。

jQuery 的承诺：让日常 UI 工作更简单

jQuery（由 John Resig 创建）之所以重要，是因为它关注日常任务：选择元素、响应用户操作、修改页面、做小动画以及发起 AJAX 请求。它提供了一套小巧且可读的 API，平滑了浏览器差异，让你能把更多时间用于构建功能，而不是与平台对抗。

在实践中，它让常见交互变得直观且可复用——可以教会别人、分享和重用。

本文关注的点

故事不仅仅是 jQuery 节省了时间。它影响了开发者的思维方式：链式操作、依赖简洁选择器、围绕事件组织 UI 代码，以及期望库提供一致的“开发者体验”。这些习惯塑造了随后出现的工具，即便在 Web 标准赶上并且新框架接管之后依然留有影响。

“让常见路径变得容易”的思路在今天的工具中依然可见。现代平台比如 Koder.ai 在不同层面应用了相同的开发者体验原则——让团队通过聊天驱动的工作流构建 Web、后端和移动应用——在过去 jQuery 让面向浏览器的 UI 代码变得易上手的地方，今天这样的平台在更高层解决类似的问题。

John Resig：项目背后的人

John Resig 并没有打算一开始就发起一场运动，他只是一个在 2000 年中期为工作而编程的开发者，感受到了大家共同的摩擦：网页上简单的事需要太多代码、会在不同浏览器出错且难以向同事解释。

一个务实的目标：让常见任务显而易见

Resig 的核心动机是清晰度。他不想让开发者记住数十种浏览器怪癖，而是希望用一小组命令来匹配人们构建页面时的思路："找到这个元素"、"改变这个"、"当用户点击时，做那件事"。jQuery 的目的不是炫耀技巧——而是减少日常挫败，帮助普通项目能够按时交付。

同样重要的是对典型 Web 开发者的同理心。大多数人并不是在做实验性演示；他们在截止日期前维护营销站、管理面板和产品页面。jQuery 专注于紧凑且可读的 API，正是反映了这种现实。

早期分享并倾听反馈

jQuery 之所以传播，是因为它易学且易于传递。Resig 做了演讲和演示，展示了立竿见影的收益，项目很快就以优秀的文档和亲和的示例闻名。这很重要：当一个工具能让你在几分钟内解决真实问题，你就会告诉其他开发者。

早期社区强化了这个循环。人们分享代码片段、编写插件并报告 Resig 无法单独测试到的浏览器与设备边缘情况。jQuery 在公众视野中成长，反馈影响了什么保持简洁，什么需要被平滑处理。

不是偶像崇拜——只是良好的产品直觉

把 jQuery 简化为某个“天才时刻”很诱人，但更真实的故事是坚持与判断力：发现普遍痛点、为日常工作流程设计、通过一致性建立信任。Resig 不只是写了代码——他创建了一个看起来像是对现实 Web 工作方式友好的快捷工具。

jQuery 出现前的网络：真实的痛点

在 jQuery 之前，编写“简单”的交互行为通常意味着把一堆浏览器特定的技巧拼在一起。你完全可以构建丰富的界面，但代价是时间、耐心和大量测试。

找到元素比听起来更难

现在，抓取一个按钮并改变它的文本看起来像一行代码。那时候，DOM 选择不一致且笨拙。某些浏览器支持方便的方法，另一些则不支持，你可能需要混合使用 getElementById、getElementsByTagName、手动循环和字符串检查，才能定位正确的元素。

即便你选中了需要的元素，你也常常要写额外代码来处理集合、把它们转换成数组，或绕过奇怪的边缘情况。

事件是跨浏览器的头疼事

点击处理、按键和 hover 都是常见需求——但浏览器在事件绑定和事件对象上意见不一。在一个浏览器中完美运行的代码在另一个浏览器可能静默失败。

开发者写了规范化事件处理的包装器："如果这个 API 存在就用它；否则回退到那个"。这意味着更多代码、更多调试以及更多可能出错的地方。

AJAX 听起来像专家才能做的事

异步请求是可行的，但并不友好。设置 XMLHttpRequest 通常涉及多个步骤、为不同浏览器写分支逻辑以及仔细处理响应状态。

一个小功能——比如在不刷新页面的情况下提交表单——可能膨胀成几十行代码，加上重试、错误处理和浏览器测试。

真正的代价：可靠性和团队速度

最大的问题不是写一次代码；而是保持它在各处都可用。团队需要的是可依赖、易学且一致的方案，让新开发者能够在不背诵浏览器兼容性清单的情况下参与贡献。jQuery 的出现正是对这种日常摩擦的回答。

大想法：为常见 UI 任务提供小而精的 API

jQuery 的突破并不是新增了浏览器能力——而是提出了一种新的思考日常 UI 工作的方式。与其为找到元素、更新它并绑定事件而写大量浏览器特定的 JavaScript，jQuery 把日常工作浓缩为一个简单模式：先选中某些东西，然后对它做点事。

“先找，再做”

核心是 $() 函数。你传入一个类 CSS 的选择器（或一个元素），得到一个 jQuery 对象——一个易用的匹配元素封装。

从那里，你可以调用像是任务的那些方法：添加类、隐藏元素、更改文本、附加点击处理。重点不是暴露每个低层细节；而是覆盖几乎每个站点都需要的 80% UI 务。

链式调用：更少变量、更清晰意图

jQuery 鼓励一种流式风格，每一步返回相同的 jQuery 对象，这样你就可以把操作串成一行可读的代码：

$(".notice")
  .addClass("active")
  .text("Saved!")
  .fadeIn();

即便你不理解内部实现，也能读懂这个“故事”：找到通知、标记为激活、设置信息、显示它们。

小而一致的 API 为什么重要

在 jQuery 之前，开发者不断问："哪个方法在这个浏览器工作？"或"这个属性在旧版本中是不是叫别的名字？"jQuery 用一套一致的方法和可预测的行为回答了这些问题。初学者有了温和的上手曲线，专业人士获得速度：更少自定义帮助函数、减少兼容性 hack 和更少需要审查的代码。

以任务为中心的脚本成为常态

由于 API 紧凑且方法名与 UI 意图直接映射，jQuery 促使团队编写更易读的脚本。你可以把代码看作一系列 UI 操作而非零散的 DOM 调用和临时变量——这让前端工作更像是组合明确步骤，而不是与浏览器扭打。

选择器与 Sizzle：“找到它”变得易如反掌

jQuery 最有说服力的技巧之一是让任何 UI 任务的第一步变得简单：选择正确的元素。你不再需要记住浏览器特定的 DOM 方法和它们的怪癖，而是可以写出看起来像 CSS 的东西，并立刻明白它的含义。

把 CSS 选择器作为熟悉的思考模型

设计师和前端开发者已经习惯于用选择器思考："抓取 header 里的所有 .button"、"定位第一个项目"、"找出某一类型的 input"。jQuery 把这种思维变成了 JavaScript 工具：

• $(".nav a") 用于操作导航中的链接
• $("#signup-form input[type=email]") 找到特定字段
• $("ul li:first") 用于快速的“第一个项目”逻辑

这种可读性很重要。它减少了从“我想要什么”到“DOM 希望我如何请求它”之间的翻译成本。

Sizzle 做了什么（以及它为何重要）

$(selector) 背后是 Sizzle，jQuery 的选择器引擎。早期浏览器并不一致地支持某些选择器，甚至对同一选择器有不同解释。Sizzle 提供了统一的解析与回退行为，因此 $(".card \u003e .title") 不会成为浏览器的碰运气。

结果是实实在在的生产力提升：更少的条件分支、更少的“如果是 IE 就……”的兼容写法，以及更少的时间花在调试为什么一个选择器在某些浏览器匹配而在另一些不匹配上。

权衡：便利性 vs 隐藏的复杂性

选择器的强大也隐藏了代价：

• 代价高的选择器会影响性能，尤其在频繁运行（例如滚动或调整大小处理器中）时。
• 很容易过度选择，然后用链式调用“以后再修复”——看起来干净的代码可能做了比你意识到更多的工作。
• 依赖复杂选择器有时会鼓励把 JavaScript 行为与脆弱的 DOM 结构紧密耦合。

尽管如此，对于日常界面工作来说，“找到它”变得容易是一个重大转变，也是 jQuery 感觉像超能力的主要原因之一。

事件、DOM 更改与效果：日常工具箱

对于许多开发者来说，jQuery 不是“一个库”——而是你构建交互时随手可拿的日常工具集。它把常见的 UI 工作转化为几次可预测的调用，即便浏览器在细节上有差异。

没有浏览器惊讶的事件处理

在 jQuery 出现之前，绑定一个点击处理可能意味着在不同的事件模型和奇怪的边缘情况之间周旋。jQuery 的 .on()（以及早期的 .bind()/.click()）提供了一种一致的方式来监听 click、submit、键盘输入等用户动作。

它也让“页面就绪时运行这段代码”变得显而易见：

$(function () {
  // safe to touch the DOM
});

这个习惯减少了典型页面的时序错误——不再怀疑元素是否已存在。

可以背下来的 DOM 操作

jQuery 的 DOM API 故意保持小而实用。需要更新内容？用 .text() 或 .html()。需要构建 UI 片段？('\u003cdiv\u003e...\u003c/div\u003e') 再用 .append()。需要控制视觉状态？.addClass()、.removeClass() 和 .toggleClass()。

开发者可以专注于想要改变的东西，而不用处理 className、属性怪癖和不一致的节点方法之间的差异。

卖相十足的效果（有时太过）

内置动画如 .hide()、.show()、.fadeIn() 和 .slideToggle() 让页面以最少的努力看起来更生动。设计师喜欢，项目负责人也会注意到，教程常常依赖这些效果。

缺点是：效果很容易被滥用——太多的淡入淡出和滑动会让界面显得缓慢或噱头化。不过对于典型交互（菜单、手风琴、通知）来说，jQuery 降低了“让它看起来精致”的门槛。

在事件、DOM 更改和效果方面，真正的胜利是简单性：日常工作中更少的边缘情况，以及一套团队能快速学会的通用模式。

AJAX 变得更亲民

在 jQuery 之前，“AJAX” 听起来像个技巧：在不重新加载整页的情况下更新部分页面。通俗来说，它就是浏览器在后台发送请求、接收数据（通常是 HTML 或 JSON），然后更新页面让用户继续操作。

从 XMLHttpRequest 到一行调用

底层的浏览器功能是 XMLHttpRequest，但直接使用它意味着很多重复代码：创建请求、监听状态、解析响应、处理浏览器差异。

jQuery 把这些复杂性封装成日常工具：

• $.ajax() 用于全面控制
• $.get() / $.post() 用于简单请求
• .load() 将 HTML 请求并注入到元素中

你不必再自己绑定事件处理、拼接查询字符串或手动解析响应，而可以把精力放在用户接下来应该看到什么上。

感觉“现代”的日常用法

这些模式很快在网站间变得普遍：

• 输入即搜（Search suggestions）：输入时获取一小段列表并渲染在输入框下方
• 无跳转表单提交：发送字段并显示成功或内联错误
• 仪表盘局部刷新：轮询更新、替换表格、更新计数器

即便服务器比较传统，jQuery 也让界面感觉更响应式。

人们容易犯的错误

jQuery 让发起请求容易，但并不总是让它们正确完成。常见错误包括：

• 薄弱的错误处理：假定成功，忽略超时、服务器错误或错误的 JSON
• 竞态条件：多个请求以不同顺序返回并覆盖 UI
• 静默失败：网络断开时没有用户提示

API 降低了入门门槛，但也传达了一个教训：仅处理“顺利路径”只是建设可靠界面的一半。

插件：放大 jQuery 能力的生态系统

jQuery 不仅仅是一个你下载的库——它是一个可以在其上构建的平台。“插件”是附加的小扩展，通常通过向 $.fn 附加函数来扩展 jQuery。对于开发者而言，这意味着你可以把一个功能放进来，然后用你已经熟悉的风格去调用它。

插件为何能快速传播

门槛很低。如果你会 jQuery，你已经理解插件模式：选择元素，调用方法，传入选项。

更重要的是，jQuery 的约定让不同作者写的插件看起来也颇为一致：

• 命名：$('.menu').dropdown() 看起来像原生的 jQuery 方法。
• 链式：优秀的插件会返回原始选择，让你可以继续链式调用：$('.btn').addClass('x').plugin().fadeIn()。
• 选项对象：配置通常像 { speed: 200, theme: 'dark' }，易于复制和调整。

人们用插件做什么

插件覆盖了原始 DOM 工作与完整应用框架之间的“缺失中间地带”。常见类别包括轮播与走马灯、表单验证、模态与灯箱、日期选择器、自动完成、提示与表格助手。

对于许多团队，尤其是负责大量营销站或内部工具的团队，插件能把数周的 UI 工作缩短为一天的组装工作。

权衡代价

插件热潮有代价。质量参差不齐，文档可能很薄弱，组合多个插件时有时会导致冲突的 CSS 或事件处理。依赖蔓延也变成现实：一个特性可能依赖另外两个插件，而每个插件都有自己的更新历史。当作者不再维护时，未维护的插件会把项目锁在旧版 jQuery 上——或成为安全和稳定的风险。

jQuery UI 与 jQuery Mobile：面向大众的组件

jQuery 的核心让 DOM 工作可预测，但团队仍然要从头构建界面组件。jQuery UI 弥补了这一空缺，提供了一系列现成组件——日期选择、对话框、选项卡、滑块、手风琴、可拖拽/可排序行为——封装好以便跨浏览器无痛使用。对于那些大量交付营销站或内部工具的小团队和代理商来说，这种“够用就好”的价值难以抗拒。

jQuery UI 为什么像生产力作弊器

重大收益不只是小部件本身，而是小部件加上一致的 API 与主题化能力。你可以通过插入对话框或自动完成快速做原型，然后用 ThemeRoller 调整外观，而不用为每个项目重写标记和 CSS 模式。这种可重复性让 jQuery UI 更像是一个实用工具包，而不是设计系统。

jQuery Mobile 对早期移动 Web 的押注

jQuery Mobile 试图解决一个不同的问题：早期智能手机浏览器能力不一致且 CSS 支持有限，响应式设计惯例尚未定型。它提供了触控友好的 UI 组件和带 Ajax 页面过渡的“单页”导航模型，目标是让一个代码库表现得类似原生应用。

为什么这些东西有些过时了

随着 Web 标准进步——CSS3、更好的移动浏览器，以及后来原生表单控件与布局原语的出现——一些抽象反而变成了累赘。jQuery UI 的小部件可能比较沉重、难以保证无障碍以及难以和现代设计预期对齐。jQuery Mobile 的 DOM 重写和导航模型也与后来像响应优先布局和框架驱动路由的做法相冲突。

尽管如此，这两个项目证明了一个关键观点：共享的、可重用的 UI 组件确实能显著加速实际交付。

jQuery 如何改变前端编码习惯

jQuery 不仅让浏览器表现良好；它还改变了“正常”前端代码的模样。团队开始每天写 JavaScript，而不仅仅是为了特殊页面，因为常见的 UI 任务突然变得可预测。

流畅的 API 与链式使用习惯

jQuery 带来的最大文化转变之一是链式调用的普及：选中某个东西，然后在可读的流程中继续操作它。

$(".card")
  .addClass("active")
  .find(".title")
  .text("Updated")
  .end()
  .fadeIn(200);

这种流式风格影响了后来的库，甚至现代原生 API。它也促使开发者倾向于小而可组合的操作，而不是庞大的一体化函数。

“用更少代码做更多事”（及其代价）

jQuery 的帮助函数——$.each、$.map、`$.extend``、AJAX 快捷方法——让把逻辑压缩成更少行的写法变得诱人。这提高了开发速度，但也鼓励了“聪明”的一行代码写法和隐式行为，可能在几个月后难以维护。

许多代码库把业务逻辑直接混进点击处理器里，因为“就地处理”非常容易。这种便利加速了交付，但通常增加了长期复杂度。

直接操作 DOM 的时代的测试与调试

在组件化和可预测状态模型普及之前，jQuery 应用经常把状态存储在 DOM 中：类、隐藏输入和 data 属性。调试意味着检查活跃的 HTML 并逐步跟踪可能以意想不到顺序触发的事件回调。

单元测试是可能的，但团队更常依赖手动 QA 和浏览器开发者工具。问题经常与时序相关（动画、AJAX、事件冒泡），这让错误显得间歇性且难以重现。

jQuery 保持整洁 vs 变得纠缠的情况

当团队：

• 把 DOM 查询限制在接近其影响元素的地方
• 使用小函数和事件委托
• 把插件当作可复用构建块

jQuery 代码往往能保持可维护性。

当页面累积了层层处理器、到处重复的选择器和动画回调内的“再多做一点”修改时，代码就会变得纠缠。这个库让快速迭代变得容易；是否能长期撑住，取决于团队的纪律性。

为什么 jQuery 渐行渐远：标准成熟了

jQuery 并不是一夜之间消失，也不是因为变差而被放弃。它之所以重要性下降，是因为浏览器平台不再需要一个“翻译器”。jQuery 曾经平滑过的问题——缺失 API、不一致行为和繁琐的工作流——随着标准成熟与浏览器趋同而减少。

浏览器开始借鉴最佳做法

随着 DOM 和 JavaScript API 的标准化，许多常见的 jQuery 调用得到了原生等价实现：

• 选择元素：document.querySelector() 和 document.querySelectorAll() 覆盖了曾经需要 $(...) 的大部分用例。
• 事件：addEventListener() 变得普遍可靠，消除了大量跨浏览器事件处理工作。
• 网络请求：fetch()（和后来的 async/await）让 AJAX 风格的调用变得原生且可读。

当“原生方式”在各浏览器间一致时，依赖一个辅助库的理由就缩小了。

性能与打包体积开始更受重视

随着 Web 应用从少量交互向完整产品发展，团队开始更严肃地关注加载时间和 JavaScript 成本。为了一些便利功能而引入 jQuery（加上插件）越来越难以证明合理性——尤其是在移动网络上。

这并不是说 jQuery 本身慢；而是“再加一个依赖”成为了一个真实的权衡。开发者越来越偏好更小、针对性的实用库——或者在平台已能满足需求时直接不用库。

SPA 改变了“前端工作”的含义

单页应用框架把注意力从手动操作 DOM 转向管理状态与用组件组合 UI。在 React/Vue/Angular 的思路中，你通常不会去问页面“找到这个元素并修改它”，而是更新数据，让 UI 重新渲染。

在这种模型下，jQuery 的强项——命令式 DOM 操作、效果和一次性事件绑定——变得不再核心，有时甚至被主动避免。

公正的看法：jQuery 成功得让自身变得可选

jQuery 的使命是让 Web 可用且一致。随着浏览器赶上，jQuery 变得不再必要——但并非不重要。大量生产环境站点仍在使用它，现代 API（和开发者期望）也反映了 jQuery 教会整个生态的教训。

遗产：jQuery 留下了什么

jQuery 不再是新前端工作的默认选择，但它仍然以静默方式支撑着网络的很大一部分——它的影响已融入许多开发者对 JavaScript 的思考方式中。

jQuery 仍然出现的地方

你最常会在那些优先考虑稳定性而非重写的场景遇到 jQuery：

• 在 jQuery 高峰期构建并仍在运行的遗留业务应用
• CMS 主题和插件（特别是旧版 WordPress 环境）
• 营销页面上的“快速修复”脚本：这里一个轮播、那里一个模态框

如果你在维护这些项目，优势是可预测：代码通常易于理解、文档充足且通常容易修补。

超越库而存活的理念

现代工具并没有逐字逐句复制 jQuery，但它们吸收了 jQuery 最佳的直觉：

• 可用的 API：用少量可读调用完成常见任务
• 选择器作为核心概念："找到元素，然后对它做事" 成为常态
• 可扩展性：插件思维延续为包生态与组件模式

即便是原生 JavaScript 的演进（比如 querySelectorAll、classList、fetch 以及更好的事件处理）也反映了 jQuery 为日常开发者解决的问题。

今天从 jQuery 学到的东西

最大的一课是产品思维：一套小而一致的 API 加上优秀文档，能改变整个行业的代码写法。

它也提醒我们“开发者体验”（DX）的复利效应。jQuery 时代的 DX 是把浏览器怪癖藏在干净的 API 后面；今天它也可能意味着压缩从想法到运行软件的路径。这也是为什么像 Koder.ai 这种以体验为中心的平台能吸引很多团队：你可以在聊天界面中快速迭代，生成带有 Go + PostgreSQL 后端的 React 前端（或 Flutter 移动应用），并在需要完全控制时导出源码。

现在如何选择合适的工具

• 对于 新项目，优先使用现代 DOM API 和框架原生模式。
• 对于 现有 jQuery 代码，不要仅仅为了替换而重写——当重构能减少风险或成本时再做。
• 对于 小型、一次性的 UI 行为，通常原生 JS 就足够；如果 jQuery 已经加载，它仍然是务实的捷径。

$(function () {
  // safe to touch the DOM
});