2006 年，John Resig 发布了 jQuery。它并没有试图重新定义 JavaScript，而是把当时常见、繁琐且容易受浏览器差异影响的任务，整理成了一组更容易使用的 API：操作 HTML、绑定事件、制作动画，以及发起 Ajax 请求。
二十年后，前端开发已经被现代框架、模块系统和构建工具重新塑造，但 jQuery 仍然存在于大量网站中。理解它为什么成功，也有助于我们判断今天的技术选择：一个库不一定需要复杂，降低日常开发的摩擦本身就是重要价值。
jQuery 解决了什么问题
早期 Web 开发的难点，往往不是业务逻辑，而是浏览器之间的行为差异和重复代码。开发者需要手动查找 DOM 节点、处理事件兼容性、修改元素内容，还要为异步请求编写相对冗长的代码。
jQuery 将这些操作压缩成了统一的调用方式。例如，下面的代码可以完成元素查找、文本更新、点击事件绑定和简单动画：
<button id="load-message">加载消息</button>
<p id="message">等待操作</p>
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
<script>
$("#load-message").on("click", function () {
$("#message")
.text("消息已加载")
.hide()
.fadeIn(250);
});
</script>
这段代码的关键不在于语法更短，而在于它把多个底层步骤组合成了清晰的意图：找到按钮、监听点击、更新文本，再让内容出现。对当时的开发者来说，这种一致性显著降低了编写交互页面的门槛。
从 DOM 操作到 Ajax
jQuery 的影响力还来自它覆盖了 Web 开发中最常见的几类任务。
- 使用选择器查找和修改 HTML 元素。
- 使用统一接口绑定事件。
- 使用链式调用组合样式变化和动画效果。
- 使用 Ajax 与服务器交换数据，而不必重新加载整个页面。
例如，在已有的 jQuery 项目中，可以这样发起一个 GET 请求。运行前请把 URL 替换成项目实际提供 JSON 的接口：
$.getJSON("/api/status")
.done(function (data) {
$("#message").text(data.message);
})
.fail(function () {
$("#message").text("请求失败，请稍后重试");
});
今天，原生 fetch、现代浏览器 API 和前端框架已经覆盖了许多相同场景。但在维护旧系统时，理解 jQuery 的选择器、事件模型和 Ajax 约定，仍然是排查问题和控制改动范围的实用技能。
为什么它的使用率下降了
jQuery 的衰退并不意味着它曾经的设计失效。随着浏览器标准逐步统一，原生 JavaScript 提供了更多能力；与此同时，React、Vue 等现代框架开始管理组件状态、渲染流程和更大规模的应用结构。
两者解决的问题并不完全相同。jQuery 更像是一套方便直接操作页面的工具，而现代框架通常会建立一套组件化的应用模型。当页面规模扩大、状态关系变复杂时，单纯依靠 DOM 操作可能难以维护；但对于服务器渲染页面、后台管理系统、营销页面或历史项目中的局部交互，jQuery 仍可能足够简单有效。
维护旧项目时可以怎样判断
是否继续使用 jQuery，应该由项目约束决定，而不是由技术潮流单独决定。可以从几个问题开始检查：
- 项目是否已经大量依赖 jQuery 插件和现有选择器？
- 当前需求只是增加一个局部交互，还是需要引入完整的组件状态管理？
- 团队是否有足够测试覆盖，以支持一次大规模迁移？
- 新增代码能否与现有模块保持一致，而不制造两套互相冲突的写法？
如果只是修复或扩展稳定的旧页面，保留现有 jQuery 依赖通常能减少风险。若是新建复杂、长期演进的应用，则应根据组件化、状态管理、性能和团队能力重新评估技术栈。
二十年后的启示
jQuery 最值得记住的地方，不只是 $ 符号或链式调用，而是它展示了一个基础工具如何通过统一 API 消除平台差异，并让更多人能够参与 Web 开发。
技术会变化，问题却会反复出现：如何减少重复代码，如何统一接口，如何让常见任务更容易完成。今天选择库或框架时，可以继续沿用这个判断标准：它是否真正降低了目标场景的复杂度，是否与项目生命周期匹配，以及迁移成本是否值得承担。