2006年1月14日，John Resig在纽约市的BarCamp大会上首次发布了名为jQuery的JavaScript库。二十年后的今天，jQuery团队欣然宣布正式发布jQuery 4.0.0版本。历经漫长的开发周期和多次预发布版本，jQuery 4.0.0带来了诸多改进与现代化升级。这是近十年来的首个重大版本更新，包含若干破坏性变更，升级前请务必仔细阅读以下说明。不过我们预计大多数用户只需对代码进行最小程度的修改即可完成升级。
许多破坏性变更其实是团队多年来想做却无法在补丁或次要版本中实现的。我们精简了遗留代码，移除了部分已废弃的API，删除了公共函数中从未文档化的内部参数，并取消了对某些过于复杂的“魔法”行为的支持。
我们已准备好升级指南和jQuery Migrate插件协助过渡。请升级后如遇问题及时反馈。
本次更新如常发布于我们的CDN及npm包管理器。其他第三方CDN预计也将陆续提供更新，但请注意我们无法控制其发布时间，需预留相应时间。以下是jQuery 4.0.0的主要更新亮点：
jQuery 4.0不再支持IE 10及更早版本。可能有人会问为何未移除IE 11支持。我们计划分阶段移除支持，下一步将在jQuery 5.0中实现。当前阶段，我们将首先移除针对 IE 11 之前版本的专项支持代码。
同时终止对其他过时浏览器的支持，包括：Edge Legacy、iOS 系统前三个版本、Firefox 前两个版本(Firefox ESR 除外)以及 Android 浏览器。您的代码无需进行任何修改。若需支持上述浏览器，请继续使用 jQuery 3.x 版本。
jQuery 4.0新增对可信类型的支持，确保以可信HTML 作为 jQuery 操作方法的输入时，不会违反 require-trusted-types-for 内容安全策略指令。
此外，虽然部分AJAX请求已使用<script>标签来维护crossdomain等属性，但我们已将大多数异步脚本请求切换为使用<script>标签，以避免因使用内联脚本引发的CSP错误。仍有少数场景使用XHR进行异步脚本请求，例如传递“headers”选项时(请改用scriptAttrs！)，但我们现已尽可能统一采用<script>标签。
当main分支上的jQuery源代码从AMD迁移至ES模块时，堪称里程碑时刻。尽管 jQuery 源代码始终随版本发布在 npm 和 GitHub 上，但此前无法直接作为模块导入——必须通过 jQuery 专用的构建工具 RequireJS。如今我们已切换至 Rollup 进行打包，并单独运行所有 ES 模块测试。这使得 jQuery 通过 <script type=module> 标签实现了与现代构建工具、开发流程及浏览器的兼容性。
这些函数在多个版本中已被标记为废弃。随着重大版本的发布，现正式移除这些函数。它们要么始终定位为内部功能，要么已在所有支持的浏览器中拥有原生替代方案。移除的函数包括：
jQuery.isArray、jQuery.parseJSON、jQuery.trim、jQuery.type、jQuery.now、jQuery.isNumeric、jQuery.isFunction、jQuery.isWindow、jQuery.camelCase、jQuery.nodeName、jQuery.cssNumber、jQuery.cssProps 以及 jQuery.fx.interval。
请改用原生等效方法，如 Array.isArray()、JSON.parse()、String.prototype.trim() 和 Date.now()。
废弃 API 的移除结合对旧版 IE 的支持代码删除，最终使压缩后文件大小减少了超过 3k 字节。
jQuery原型中长期存在着与其他方法行为迥异的数组方法，这些方法始终仅限于内部使用。这些方法包括push、sort和splice。现已从jQuery原型中移除。若您曾使用这些方法，可将$elems.push( elem )替换为[].push.call( $elems, elem )。
长期以来，浏览器对焦点事件(包括 focusin、focusout、focus 和 blur)的触发顺序存在分歧。如今 jQuery 4.0 支持的所有浏览器最新版本终于统一了事件顺序。遗憾的是，该顺序与 jQuery 多年前确立的规范不符，因此构成破坏性变更。至少现在大家终于达成共识了！
从 jQuery 4.0 开始，我们不再覆盖原生行为。这意味着除 IE 之外的所有浏览器都将遵循当前 W3C 规范：
而 jQuery 旧版本的顺序为：focusout, blur, focusin, focus。讽刺的是，唯一曾遵循旧版W3C规范(2023年更新前)的浏览器竟是Internet Explorer。
jQuery 4.0.0通过移除Deferreds和Callbacks进一步缩减了精简版体积(gzip压缩后约19.5k字节！)。Deferreds 长期支持 Promises A+ 标准，因此在多数情况下可改用原生 Promise，且除 IE11 外所有 jQuery 支持的浏览器均可使用。虽然 Deferreds 具备原生 Promise 不支持的额外功能，但绝大多数用法均可迁移至 Promise 方法。若需支持IE11，建议使用主构建版本或为原生Promises添加polyfill。
您可从jQuery CDN获取文件，或直接链接至：
https://code.jquery.com/jquery-4.0.0.js
https://code.jquery.com/jquery-4.0.0.min.js
也可通过 npm 安装：
npm install jquery@4.0.0
有时您可能不需要ajax功能，或更倾向于使用专注于ajax请求的独立库。此外，通过CSS与类操作组合实现网页动画往往更为简洁。最后，除IE11外，所有jQuery支持的浏览器现已全面原生支持Promises，因此在多数情况下不再需要Deferreds和Callbacks。除包含完整功能的常规版外，我们还发布了剔除这些模块的“精简版”。如今jQuery体积极少成为加载性能问题，但精简版经gzip压缩后比常规版小约8k字节。这些文件同样可在npm包管理器和CDN获取：
https://code.jquery.com/jquery-4.0.0.slim.js
https://code.jquery.com/jquery-4.0.0.slim.min.js
这些更新已在npm和Bower上作为当前版本发布。获取jQuery的所有方式详见https://jquery.com/download/。公共CDN今日已接收更新文件，请等待数日更新完成。若需快速启动，可先使用我们CDN上的文件，待其更新后再行替换。
衷心感谢所有参与本次版本发布的同仁，包括提交补丁、报告漏洞或参与测试的Alex、 艾哈迈德·S·埃尔-阿菲菲、fecore1、达拉斯·弗雷泽、理查德·吉布森、 Michał Gołębiowski-Owczarek、Pierre Grimaud、Gabriela Gutierrez、Jonathan、 内克梅廷·卡拉卡亚，安德斯·卡塞奥格，金元燮，西蒙·莱格纳， 沙尚卡·纳塔拉吉、帕特·奥卡拉汉、克里斯蒂安·奥利夫、 迪米特里·帕帕多普洛斯·奥尔法诺斯、朴元亨、布鲁诺·皮埃尔、 任宝硕，比阿特丽斯·雷泽纳，肖恩·罗宾逊，埃德·桑德斯， 蒂莫·蒂霍夫、汤姆、克里斯蒂安·温茨、ygj6 以及整个 jQuery 团队。
过去二十年间，众多杰出人士为jQuery及其相关项目做出了贡献，我们中的许多人齐聚达拉斯参加了一场重聚活动。John Resig甚至通过Zoom参与其中。本次发布正是在我们共聚一堂时发布的。
完整更新日志： 4.0.0
processData: true (ce264e07)headers 参数 (#5142, 6d136443)jQuery.get 中支持将 null 作为成功函数 (#4989, 74978b7e).attr( name, false ) 移除所有非 ARIA 属性 (#5388, 063831b6)toggleClass(boolean|undefined) 签名 (#3388, a4421101)<col>元素的尺寸问题 (#5628, eca2a564)selector.js 包装器 (53cf7244)offsetHeight( true ) 等方法包含负边距(#3982, bce13b72)undefined (#5120) (7eb00196)addClass( array ) 中跳过假值，压缩代码 (#4998, a338b407)show、hide 和 toggle 方法 (297d18dd)$.parseHTML 从 document.implementation 切换至 DOMParser (0e123509)src/ 中使用命名导出 (#5262, f75daab0)getStackHook 重命名为 getErrorHook (#5201, 258ca1ec)3.x-stable 版本对齐 (d9281061)trac-NUMBER 引用 (eb9ceb2f)#NUMBER Trac 问题引用替换为 trac-NUMBER (5d5ea015).preventDefault() (7c123dec).on(focus).off(focus) 后破坏焦点触发机制 (#4867, e539bac7)npm publish (ff1f0eaa):has 的临时解决方案；在 iPhone 和 iPad 上均进行测试 (65e35450)jQuery.expr[ “:” ]/jQuery.expr.filters (329661fd)selector.js 模块依赖于 attributes/attr.js (#5379, e06ff088)selector.js 的依赖 (e8b7db4b)qSA (#5177, 09d988b7)uniqueSort (#5166, 5266f23c)CSS.supports(selector(...)) 不兼容，则使用 jQuery :has (#5098, d153c375)<object> 上的 contents() 方法 (ccbd6b93)<object> 对象上的 contents() 方法 (#4384, 4d865d96)
本文由 TecHug 分享，英文原文及文中图片来自 jQuery 4.0.0。
早年人们常使用BackboneJS[1]实现此类需求。令人惊讶的是，它至今仍在积极维护中[2]。
若因历史遗留原因仍需使用jQuery，BackboneJS可作为迈向现代框架的理想过渡方案。该框架轻量且易于掌握
[2]: https://github.com/jashkenas/backbone/tags
-- augusto-moura这让我想起多年前jQuery的意大利面代码怪兽，其中不乏Backbone相关案例。回过头看，过度设计的React代码可能比结构合理的jQuery代码更糟糕，但某些jQuery乱码确实比任何React代码都更不堪。所以我想说的是：React确实提升了质量门槛和标准——但有时过度追求反而适得其反，审慎使用熟悉的老工具反而能高效完成任务。
-- lioeters你让我想起2021年初某位客户要求我在React/Redux构建的文件上传器上添加功能的事。
绝非虚言，当时存在30多个Redux动作以极其晦涩的方式串联，表单仅包含文本输入框、文件浏览器按钮和提交按钮。
罗马尼亚团队耗费数周才搭建完成，后来该团队被调离岗位，导致无人能接手维护。
我记得自己写了满满几页笔记才理清那些极其复杂的动作链，几小时后成功简化流程——删掉几个动作就宣告进展。太棒了。
突然间我恍然大悟：我完全可以重写代码。
短短数小时内，我彻底清除了那堆垃圾代码，用单一的useState替换，同时实现了新需求功能。
客户对我的进展难以置信，更惊讶于我同时解决了他们之前遗留的诸多问题。
随后我有了第二个顿悟：React同样毫无用处，最终弃用转而采用原生HTML表单和少量JS回调。
-- epolanski> 我没开玩笑，当时有30多个Redux动作以最令人费解的方式串联着
我百分百相信这种描述，因为它概括了我见过的所有Redux代码库。这个库简直是间接操作的反模式典范。
-- normie3000这听起来像是工程质量问题而非工具问题。
结构良好的 Redux(或 MobX、Zustand)完全能实现高可维护性与高性能，反观那些遍布草率 useState 调用和深度属性钻取的代码库则不然。
Redux Toolkit作为内置电池的解决方案，长期以来都是使用Redux的优质选择https://redux-toolkit.js.org/
但Redux在React早期阶段的流行，导致大量Redux代码库至今仍存续，其中许多已成为遗留系统。
-- gejose实在无法理解有人竟为简单用例编写30个Redux动作——毕竟有人已实现完全相同的方案。不过确实，我自己也不太喜欢Redux。
-- Capricorn2481请对那些急需保障就业的资深专家架构师全栈开发者(刚从训练营毕业)心怀怜悯。
-- loglog最初的开发者并非速成班出身，而是工程专业毕业生。
正如FAANG公司充斥着靠LeetCode黑带头衔写垃圾代码的骗子，罗马尼亚显然也是如此。
-- epolanski这简直是对整个国家行业劳动力的极端概括。
若有人仅凭一则轶事(即便属实)就如此评价你的国家，你肯定会百分百赞同吧？
-- namtab00这与罗马尼亚或其他国家无关。
我想强调的是：毕业与否与处理高阶抽象概念和复杂问题的能力关联甚微——无论是编程训练营学员还是工程专业毕业生，都缺乏构建复杂系统的实战经验，更遑论在时间紧迫、技术领导和管理压力下的实战能力。
很可能原作者们曾遭遇这样的处境：上级要求用不熟悉的技术构建简单表单，结果写出了混乱不堪的代码。
-- epolanski多年前我曾用Redux构建实时流数据处理层。核心需求是接收、合并并处理多条数据流，最终汇聚成单一实时数据池。此后，实时数据的消费变得轻而易举。
即便现在，我仍不确定能否找到更适合处理实时数据和同步的工具。但对于简单的CRUD操作，Redux大多是过度设计了
-- gloryjuliohttps://rxjs.dev/guide/observer
-- hirako2000确实如此，但Rx比Redux更小众。招聘Redux开发者要容易得多
-- gloryjulioReact让复杂交互式UI的管理比jQuery轻松得多，但这也导致许多开发者仅仅因为技术可行就添加了更多复杂性。
-- root_axis我理解你的意思是React提高了门槛，但也降低了上限。
-- Sammi>> 这让我回想起多年前jQuery的意大利面代码怪兽，有些还和Backbone有关联。
公平地说，jQuery是针对2000年代初IE和JS版本混乱的解决方案。它让开发者无需在三种浏览器变体间反复调试。
-- TuringNYC我曾采用这种方法，确实比2010年代风格的jQuery混乱代码更高效。它也很适合用户脚本场景——当你试图解决的问题范围有限时，依赖项(尤其是涉及构建步骤的依赖)会带来麻烦。请注意，除非你必须支持古老浏览器，否则完全不需要 jQuery：querySelector、addEventListener、innerHtml 这些方法作为基础构建块，早已长期可用且稳定。
-- Klaster_1遗憾的是，如今编写用户脚本比以往困难得多。多数网站都采用某种响应式前端框架，因此需要大量使用mutationObservers(或jQuery中的等效实现)。
-- doix我虽非前端开发者，但设计了这个方案并在用户脚本中频繁使用。虽然效率不高(完全可以重构为创建MutationObserver单例，再让每次调用挂钩到该实例)，但完全满足我的需求，让我能用老派方式处理响应式网站(只要你接受异步操作)：
function awaitElement(selector) {
return awaitPredicate(selector, _ => true);
}
function awaitPredicate(selector, predicate) {
return new Promise((resolve, _reject) => {
for (const el of document.querySelectorAll(selector)) {
if (predicate(el)) {
resolve(el);
return;
}
}
// 创建MutationObserver监听变化
const observer = new MutationObserver((_mutations, obs) => {
// 可仅在_mutations内搜索而非整个DOM
// 效率主要取决于选择器的精确度
for (const el of document.querySelectorAll(selector)) {
if (predicate(el)) {
resolve(el);
obs.disconnect(); // 切记断开观察器连接！
break;
}
}
});
// 开始观察文档
observer.observe(document.documentElement, {
childList: true,
subtree: true,
attributes: false,
characterData: false,
});
});
}
用LLM编写代码更轻松。一次性项目(我处理用户脚本的方式)正是它们大放异彩的领域。
我用Instagram干的那些可怕事啊…
-- egeozcan继续说
-- tensegrist我常选择setInterval而非MutationObserver，因为它能稳定运行，我不需要即时响应，也不必费心去深究原理。
确实如此。这取决于你遇到问题的网站类型？我刚检查了自己的脚本，这些都是针对完全服务器渲染网站(如HN或phpBB论坛)的生活质量优化。
-- Klaster_1没错，我主要用它优化工作相关的体验——比如Jira、Bitbucket、GitHub、Linear等雇主使用的工具。2010年代初这类软件大多采用全服务器渲染，如今这种情况已相当罕见。
我懒得动手，就让大型语言模型代劳。它们偏爱用setInterval代替mutationObservers，只要能用我就忍受低效。
-- doixAtlassian套件的扩展性尤其糟糕——其UI调用的API接口多如牛毛，且绝大多数响应极其迟缓。
-- mschuster91我最后一个大型jQuery应用最终采用了类似的响应式模式。当时必须把自研搜索引擎前端硬塞进Joomla CMS框架，而我几乎没法修改任何代码。真是段难忘的经历！
-- 1123581321这确实是个很棒的模式。若添加信号，更新函数甚至会自动调用。这基本就是我们在[Reactive Mastro](https://mastrojs.github.io/reactive/)中所做的工作 😉
-- mb2100MobX会愉快地自动调用jQuery函数。
-- davidzweig至今仍是全球我最钟爱的库之一。我永远热爱jQuery，它成就了我进入(真正)企业的职业生涯。
jQuery永存！去传播吧！
-- karim79这些追逐新框架的小伙子们…jQuery和.NET框架一直养活着我！
-- sieep我的意思是…jQuery和.NET(6+)至今仍能让你吃得饱饱的 😀
-- metaltyphoon相信我，要是能由我做主，这周我就脱离框架啦哈哈哈
-- sieep深有同感，我用jQuery十五年了，它就是我的首选。
-- ei8ths真该有人把虚拟DOM接入jQuery，它拥有完整的插件生态，人工智能完全可以复用。jQuery+jQuery UI+jQuery插件+人工智能，这可能是我们都忽略的超级力量。
-- radicalethics初读时还以为你在开玩笑说虚拟 DOM 集成。但现在看来是认真的。
既然已有真实的 DOM，何必再搞虚拟的？除非你指的是 AI 目前还无法可靠地与真实浏览器交互。
-- cj每当这里提到HTMX，我总忍不住想：“这不就是用几行语法怪异的代码替换原生jQuery的三行命令式代码吗？”
反正jQuery一直能解决问题，只要它管用就永远用下去吧。
-- flomo没错：HTMX源于intercooler.js，后者基于jQuery并受jQuery.load()方法启发：
我是在某次性能优化工作中发现它的。intercooler.js最初是个自定义函数，通过自定义属性钩子拦截.load()事件(这个技巧源自Angular 1.x)
我对jQuery怀有深深的敬意与热爱
-- recursivedoubts你是Carson吗？
-- rolymath没错
-- recursivedoubtsjQuery的问题在于其命令式特性——当需要处理多项任务时，必须命令式地覆盖所有情况，导致代码迅速变得复杂。
-- gbalduzzi没错，这正是另一个HN禅宗公案：“如果你…可能就不需要React”。但若你用jQuery/原生JavaScript把状态硬塞进HTML，那你确实需要React这类框架。
-- flomo关键不在状态管理，而在DOM更新机制。
-- epolanski我部分认同这种观点，2015年的我曾是SPA的狂热信徒，但如今当我看到采用PHP和jQuery美学标记的网站(而非Facebook Marketplace那种架构)时，总会松一口气。并非说我愿意用它们编程，但欣赏它们运行(或崩溃)的可预测性，通常不会让浏览器卡死。或许是因为那些使用jQuery却幸存下来的网站，正是因为它们的复杂度始终未超过某个极低的临界点。
-- eloisius讽刺的是，Facebook其实是用PHP开发的。
-- skizm曾经确实如此，所以他们才转向HHVM进行解释执行，但如今已被名为Hacklang的PHP衍生语言几乎完全取代。
-- connorgurney我认为到2026年Facebook将演变为多元技术集合体…绝对不再仅依赖PHP。
-- ryan_n如今我已转向原生JS，但$()选择器接口相较document.getElement[s]by[attribute)]确实优雅简洁得多。
虽然原生选择器可能比jQuery慢，但或许能通过预计算优化。
-- hsbauauvhabzb若你尚未了解：请关注querySelector和querySelectorAll。它们更接近jQuery选择器系统的运作方式，我认为正是受其启发而生。
若嫌冗长，可定义简短名称的实用函数(尽管我个人不热衷此类做法)。
https://developer.mozilla.org/docs/Web/API/Document/querySel…
https://developer.mozilla.org/docs/Web/API/Document/querySel…
https://developer.mozilla.org/docs/Web/API/Element/querySele…
https://developer.mozilla.org/docs/Web/API/Element/querySele…
-- jraphbody.qsa(‘.class’).forEach(e=>): 是的，在Node原型中添加qs()和Array.from(qsa())别名，并在window中添加.body属性，就能省下成千上万次键盘敲击。之后若想发挥创意，可以尝试使用Proxy，但我从未觉得有必要。
-- hyperhello不过请别乱改原生原型。
-- jraph如果你是库开发者，请同意此观点。若你是应用或网站开发者，那这是你的项目。其他人应避免向原生原型添加内容，以确保最终用户体验的纯净性。
-- Sammi作为应用或网站开发者，至少你不会破坏他人的系统。
但你仍可能破坏自身项目。试想：当你为原生原型扩展方法后，原生原型后续却新增了同名方法。
新版本库开始采用这个标准方法。
当你升级网站依赖的库或新增依赖时，新代码恰好依赖该原生原型。而你早已用自定义方法覆盖了它——且该方法行为必然存在差异。你破坏了新代码的运行，而修复过程可能相当棘手——因为自定义方法的调用遍布代码各处。
这种做法仅适用于零依赖项目，或依赖项永不更新的场景。
或者你可以规避风险，直接定义一个带参数的节点方法。
这同样关乎良好习惯的养成：你当前在项目中可能习惯性地扩展原型，但当你编写库时，能否记得避免这种做法？
顺便问一句，你怎么能确定不会将应用程序中的某些代码移入库？毕竟你喜欢这些实用函数，并希望在其他项目中复用它们。何不将共享代码开源，直接通过NPM安装？咔嚓一声，这东西就成了库。
-- jraph> 当你升级网站依赖的库或新增依赖时，新代码恰好依赖了原生原型。而你用自定义方法替换了原型，且该方法行为可能不完全一致。你破坏了新代码的兼容性，修复过程可能相当棘手——因为自定义方法的调用遍布整个代码库。
他建议的是添加原型方法而非替换。除非所用库本身也在添加原型，否则我看不出问题所在。当然，若未来JS版本占用这些命名可能会导致故障，但我敢打赌实际应用中这根本不成问题。
-- janderland规则衍生规则。
-- hyperhello$(和$$)选择器函数在Chrome/Chromium开发工具中依然可用！
-- adzmconst $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);
jQuery却像Svelte那样被编译掉…这主意倒不赖。
-- egeozcan我不想显得像个刻板印象中的web开发者，但querySelector的解析步骤明明被缓存了，速度不至于慢到需要保留这种构建步骤。
-- efskap有些东西你构建它，并非因为必要，而是因为你有能力做到。
-- egeozcan实现非常简洁的jQuery，包含所有常用API：
(function (global) {
function $(selector, context = document) {
let elements = [];
if (typeof selector === "string") {
elements = Array.from(context.querySelectorAll(selector));
} else if (selector instanceof Element || selector === window || selector === document) {
elements = [selector];
} else if (selector instanceof NodeList || Array.isArray(selector)) {
elements = Array.from(selector);
} else if (typeof selector === "function") {
// DOM ready
if (document.readyState !== "loading") {
selector();
} else {
document.addEventListener("DOMContentLoaded", selector);
}
return;
}
return new Dollar(elements);
}
class Dollar {
constructor(elements) {
this.elements = elements;
}
// Iterate
each(callback) {
this.elements.forEach((el, i) => callback.call(el, el, i));
return this;
}
// Events
on(event, handler, options) {
return this.each(el => el.addEventListener(event, handler, options));
}
off(event, handler, options) {
return this.each(el => el.removeEventListener(event, handler, options));
}
// Classes
addClass(className) {
return this.each(el => el.classList.add(...className.split(" ")));
}
removeClass(className) {
return this.each(el => el.classList.remove(...className.split(" ")));
}
toggleClass(className) {
return this.each(el => el.classList.toggle(className));
}
hasClass(className) {
return this.elements[0]?.classList.contains(className) ?? false;
}
// Attributes
attr(name, value) {
if (value === undefined) {
return this.elements[0]?.getAttribute(name);
}
return this.each(el => el.setAttribute(name, value));
}
removeAttr(name) {
return this.each(el => el.removeAttribute(name));
}
// Content
html(value) {
if (value === undefined) {
return this.elements[0]?.innerHTML;
}
return this.each(el => (el.innerHTML = value));
}
text(value) {
if (value === undefined) {
return this.elements[0]?.textContent;
}
return this.each(el => (el.textContent = value));
}
// DOM manipulation
append(content) {
return this.each(el => {
if (content instanceof Element) {
el.appendChild(content.cloneNode(true));
} else {
el.insertAdjacentHTML("beforeend", content);
}
});
}
remove() {
return this.each(el => el.remove());
}
// Utilities
get(index = 0) {
return this.elements[index];
}
first() {
return new Dollar(this.elements.slice(0, 1));
}
last() {
return new Dollar(this.elements.slice(-1));
}
}
global.$ = $;
})(window);
const $ = document.querySelectorAll
-- Zardoz84我通常这样写：
const $ = (s, e = document) => e.querySelector(s)
$$ 的实现类似。
-- Tistron可能需要绑定 this 值。
-- recursive至少在用Django时，我基本靠HTMX和原生JS解决大部分问题。这样既保持简洁，又能让应用具备SPA体验。
-- sgt经典的jQuery啊。
感谢你为我们所做的一切。
-- thr0waway001欣慰它仍在更新。可悲的是，这大概意味着React会存在到2060年。
-- b3ingReact有什么问题？
比起意面般的jQuery，它让应用开发高效太多。
至今想起追踪jQuery回调的噩梦就浑身发抖
-- altern8复杂的API需要深入理解内部机制及其陷阱。
摒弃类组件后，其渲染模型复杂且生命周期难以掌控。要实现高性能网站极其困难(但欢迎用React作品链接反驳我)。
更严重的问题在于：大量网站滥用React构建静态内容，这些项目根本不具备“应用程序特性”，也无需实时响应能力。超过95%的React“应用”本该采用模板语言开发。
例如Github早期使用Ruby时各方面表现都优越得多，可惜有人必须向高层推销晋升方案。
-- epolanski2021年他们发布过一篇文章[0]，详述如何结合名为Calalyst的库使用Web组件。这套系统看起来相当不错。至今我仍在HTML中看到include-fragment元素，推测他们仍在沿用该方案。
[0]: https://github.blog/engineering/architecture-optimization/ho…
-- tentacleuno它过于冗长且反直觉，而在2025年，虚拟DOM已非编写交互式网页应用的必要条件。若想开发现代网页应用，可选用Svelte；若追求真正的函数式编程，Elm才是理想选择。React不过是当代的jQuery——它在Angular时代确实功不可没，但我们正站在新时代的黎明。
-- bossyTeacher在2025年推荐Elm纯属无稽之谈——这话出自Elm爱好者之口。
-- epolanski作为非Elm爱好者，为何如此断言？我认为当下任何JS前端框架都能冻结版本沿用十年。JS具有极强的向后兼容性。
真正引入漏洞并需要持续维护的，是那些涉及服务器连接的框架。
-- Capricorn2481为何说它过于冗长？
我认为它非常直观，除了useEffect这个特性。
-- mehagarSvelte初看不错，直到你发现要获得最佳支持和功能，基本必须使用糟糕的元框架SvelteKit。
-- major_major_没错，但这与React无关：Svelte = React。
-- ezfeReact的问题在于它解决了前端开发。
因此选择只有两种：1. 整天写React代码并乐在其中；2. 编造理由指责它不好。
这个领域里许多才华横溢且求知若渴的人都倾向于选择2。
-- lopatin我认为React的问题在于它过于霸道，且为解决许多问题而过度设计得令人恼火。我使用Mithril，发现它简单得多。
-- gmac当他们开始添加新钩子来绕过自身残缺的组件/渲染生命周期时，我就知道React注定会变成臃肿的烂摊子。
正常人根本不会记得为那些冷门场景使用useDeferredValue或useEffectEvent。
这些都是React糟糕组件生命周期设计的直接后果。反观Vue的精细化生命周期钩子，既能提供所需控制权又无需绕弯子，命名也合乎逻辑[1]
更别提React那套用Context实现的全局状态管理的拙劣方案了。每次状态变更都会触发整棵树的重渲染，即便组件并未订阅该状态——简直是性能噩梦。想要订阅功能？要么手动实现，要么使用第三方状态库。但若全局状态依赖于React生态中的其他状态/数据，这些库又无法在组件渲染前完成初始化。
1. https://vuejs.org/api/composition-api-lifecycle.html
-- docmars我完全尊重人们选择避开React的决定，但作为开发过多个React应用的从业者，我仍想回应部分观点。
> 当他们开始添加新钩子来规避自身缺陷的组件/渲染生命周期时，我就知道React注定会沦为臃肿的烂摊子。
钩子并未带来根本性变革。它们只是逃离渲染循环的手段——而类组件早已具备这种能力。
> 正常人根本不会记得在极其小众的场景里使用useDeferredValue或useEffectEvent。
或许因为你未必需要它们。不过说句公道话，我在旧版React时代就用过这些功能，甚至在工作中用它们搭建过完整的单页应用。但读了文档后，感觉它们挺靠谱？
> 更别提React用Contexts管理全局状态的拙劣方案了——每次状态变更都触发整棵树的重渲染，简直是性能噩梦
我觉得有必要说明重渲染的本质：它不同于DOM重绘，甚至消耗的CPU周期数量级都不同。整个网站可能因文本输入而重渲染，但即使开发工具显示CPU降速10倍，你也很难察觉——除非你无端在渲染周期中添加耗时操作。确实有人在文本输入每次变更时执行fetch请求。而同样的降速操作在基于Svelte的Apple Music上几乎会导致崩溃。
但几乎所有其他状态管理库都能实现你描述的理想效果。
-- Capricorn2481Vue究竟优越在哪里？在我看来它只是引入了更多人为状态。
我对React的主要质疑在于其异步处理机制，但这源于异步流程本身难以建模的特性。Suspense虽有所改善，但我并不喜欢它。我强烈认为中间状态应当显式呈现。
-- cyberax我采用老派方式使用Preact，完全不依赖React引入的“use-whatever”机制。这种简洁易用的特性让我能快速完成开发，无需过度思考。
-- leptons到2060年 React Native 应该会升级到v0.93
-- mikeaskew4事实上已经存在两个 React 版本。到2060年，将会有五个版本。
-- b65e8bee43c2ed0两个 React 版本！？
-- 2muchcoffeeman当前主要分支是客户端React与服务器组件(通常搭配Node.js后端)
-- o_m作为非React用户，我知晓React Native(适用于iOS和Android)以及React(可支持服务器端渲染或客户端渲染)。
-- exac还有React Native Web
-- psnehanshu抱歉，什么？
-- underdeserver我认为这是个好主意，它能让开发者清晰定义元素结构，避免随意插入div标签。
这需要强大的设计系统支撑，可能降低某些Web API的使用便捷性，但这些权衡是合理的
-- afioriTwitter正是用React Native Web构建的
-- tcoff91若想用React开发网站同样适用
-- rauli_他们应该推出能在手机上运行的应用版本
-- neals他们已有此版本，名为React Native Web Native
-- jasongill还有react vr
-- atulvi类组件与函数组件之争
-- tcoff91这在React社区里是最无趣的分歧
-- afiori就像我确信其他在2000年代和2010年代初接触Web开发的人一样，在SPA框架尚未普及的年代，我正是通过jQuery学习Web开发脚本编写。很高兴看到它依然活跃。早期基于jQuery构建的众多项目至今仍能正常运行。向开发团队致敬。
-- giancarlostoro祝贺所有参与jQuery 4.0发布的同仁。
值得一提的是，若您寻求基于jQuery的更结构化方案，JsViews(https://jsviews.com)提供成熟稳定多年的响应式模板与数据绑定系统。
虽然它不像新框架那样广受欢迎，但对偏爱jQuery生态系统的开发者仍具吸引力。
-- alnico从未听说过JsViews，但看起来很有意思。至于其他“现代”的jQuery方案，我个人更倾向于cheerio和alpine：
-- shimman看起来很有意思。虽然近期不太可能编写 jQuery 代码，但我会研究其源代码看看能否从中汲取经验。
关于采用率问题，JsViews 官网的页面设计让我误以为自己不小心在 Iceweasel 浏览器里切换了“桌面版网站”选项，不知是否因此吓退了用户。或者正如其他人提到的，如今大多数jQuery开发都存在于遗留代码库中，开发者被禁止添加任何新库，这使得新jQuery库的采用率远低于基于jQuery用户基数预期的水平。
(不过网站确实能正常运行，加载速度也快。这正是我始终欣赏当今存活的jQuery网站之处。唯一缺失的是压缩+gzip后的文件大小提示。编辑：jsrender.js为33.74 kB，jsrender.min.js仅12.82 kB)
-- vanderZwan我一直在与JsViews的作者鲍里斯合作，我们确实计划对网站进行现代化改造——这正应了你关于第一印象和用户接受度的观点。你完全正确，呈现效果至关重要；如果界面显得过时，人们可能在深入了解前就失去兴趣。
我也向鲍里斯提出了jQuery依赖性问题，原因正是你所指出的：许多团队会自动排除任何需要jQuery的方案，尤其在非遗留代码库中。这确实是当前的实际障碍。
值得一提的是，无jQuery版本或许会实现。鲍里斯正在积极探索，但无法保证——这并非简单重构，而是需要彻底重写的重大工程。
-- alnico难以置信的是，它居然仍支持IE 11——该浏览器在jQuery 5.0中已被计划弃用
-- rationably这似乎是为了不延误4.0版本的发布。由于他们遵循半版本号规则，意味着IE 11要到5.0才被砍掉[1]。考虑到3.0版本发布已逾十年，这实在令人咋舌。
不过这次或许规划得更周全：早在2019年他们就宣称要在2020年发布4.0版本！
[1]: https://github.com/jquery/jquery/pull/5077[2]: https://github.com/jquery/jquery/issues/4299
-- indolering向后兼容性。显然仍有部分用户停留在IE11环境。jQuery持续支持这些用户及其仍在运行的产品，这点值得称道。
-- tartoran最让我费解的是这部分：
> 我们同时终止了对其他老旧浏览器的支持，包括旧版Edge、iOS近三代之前的版本、Firefox近两代之前的版本(Firefox ESR除外)以及Android浏览器。
2022年发布的iOS 16版Safari在所有可想象的方面都比MSIE 11更现代化。我敢打赌，受困于iOS 16的用户数量远超仅能使用IE 11的群体——除非是在那些IT部门极其糟糕的企业中，这种情况反而可能助长他们的低效。
我主张果断撕掉这块创可贴。MSIE已是死技术，比微软其他淘汰的浏览器更过时。让它尽快在耻辱中消亡吧。
-- kstrauser这里的“支持”大概指“我们在这些浏览器上测试jQuery兼容性”——iOS 16的Safari很可能仍能流畅运行该版本jQuery。但为这些客户端运行自动化测试套件或支持漏洞修复，远比启动微软提供的IE11虚拟机困难得多。
-- sebazzz此外，手机的升级/淘汰速度远快于桌面设备。
-- toyg言之有理。
-- kstrauser许多企业内网应用仍依赖IE，而微软至今仍在维护IE。即便在Windows 11系统中，Edge浏览器也为此保留了IE模式。反观iPhone用户若固守旧版iOS系统，则意味着已不再获得苹果官方支持。
-- layer8内部僵尸应用用旧浏览器，上网就用现代浏览器。
这些手机仍在支持范围内。最新iOS 16更新发布于2025年9月。
-- kstrauser问题很少出在糟糕的IT部门，而是某些特殊或遗留软件缺乏现代替代方案
-- croes但这些糟糕的遗留软件真会引入新版jQuery吗？
-- voxic11> 2022年发布的iOS 16版Safari，在所有可想象的方面都比MSIE 11更现代化。
仍在运行MSIE11的计算机可能数以百万计，甚至上千万。而运行iOS 16的设备可能已不复存在
-- troupo> 运行iOS 16的设备几乎不存在
我的iPhone X卡在iOS 16系统无法升级。
但手机仍运行良好。尽管每日使用长达8年，电池容量仍达81%，从未摔落过，OLED屏幕效果出色，可录制4K@60帧视频。其响应速度远超2025年售价200美元的全新安卓手机(如小米)。苹果仍持续提供安全补丁。相较现代iPhone的唯一短板是弱光拍摄表现。此外部分应用开发者已停止支持iOS 16，例如我无法使用ChatGPT应用，只能通过浏览器访问，但Gemini应用运行正常。
-- Strom据Cloudflare数据显示，当前几乎没有任何版本的MSIE用户存续。[0]
Statcounter统计显示约4.6%的iOS用户仍在使用iOS 16系统。[1]
我直觉认为，当前使用iOS 16的人数是任何版本MSIE用户的数倍之多。
[0] https://radar.cloudflare.com/reports/browser-market-share-20…
[1] https://gs.statcounter.com/os-version-market-share/ios/mobil…
-- kstrauser2020年我参观过一家酿酒厂。他们的机器由运行Windows XP的惠普笔记本电脑管理。那些机器、那些笔记本电脑以及那个Windows XP系统，很可能至今仍在使用，连同它们陈旧的IE浏览器。
-- pmontra这些设备大概会一直用到电容报废为止，但关键在于它们几乎肯定运行着某些Win32工业流程软件——这类软件根本不需要网页浏览器，甚至无需联网。考虑到老旧WinXP系统的安全漏洞，我倒希望它们没接入无线网络！
-- mortenjorck这些机器很可能根本没联网。
-- SchemaLoadXP最多只支持IE8
-- wqweto据我所知，公共统计数据往往忽略企业网络。
-- troupojQuery更新同样会遗漏这些隔离浏览器。
-- kstrauser但那些用户/产品会升级jQuery吗？
-- phinnaeus谁还在用IE11——为什么？
-- jbullock35我过去有个客户，截至2020年仍有显著比例的IE8/9/11流量。所谓显著是指百万用户中占比超10%。
这些流量遵循周一至周五8-17点的规律。
本质上是用户在工作设备(邮局、银行等)上使用企业电脑，而这些设备未安装现代浏览器。
我们专门配置了测试机，用于在IE8和IE9环境下手动验证每次版本发布。
只要用户通过这些设备访问我们的产品，我们绝不会放弃支持。
但据我所知，该客户已于2024年终止对IE8和IE9的支持，IE11也计划在今年停止维护。
-- epolanski确实存在一些极其保守的政府机构和大型企业，仍在运行十年老旧的基础设施。若这构成你的客户群体？那就得配合。此外我曾参与某消费类产品发布网站开发——你或许记得那项目——后来突然要求支持IE7，只因日本高管们用的就是这个版本。客户根本不在乎，但我们确实实现了IE7兼容。
-- flomo哦，企业使用十年老软件确实常见。但需要说明的是，IE 11今年已满13岁[1]。这反而让我更感意外。
[1] https://en.wikipedia.org/wiki/Internet_Explorer_11
-- jbullock35微软将支持IE 11至2032年。
-- layer8我理解的意思是他们会支持Edge的IE 11兼容模式直到那时，但IE 11本身已停止支持，仅保留极少数企业专用版本。
-- kstrauserIE 11桌面应用程序在多个Windows LTSC版本上仍受支持：https://techcommunity.microsoft.com/blog/windows-itpro-blog/… 其中至少Windows 10 IoT LTSC将获得支持至2032年。
-- layer8部分企业设备仍在运行XP。既然能用，何必升级？
-- ejmatta安全问题
-- ExpertAdvisor01但它依然会运行Windows广告软件版。=3
-- Joel_Mckay用企业版吧
-- LtdJorge企业版广告软件？对那些花190美元/席位换来垃圾广告的人来说简直荒谬。
总之Windows本就该待在虚拟机快照备份里。=3
-- Joel_Mckay我认为任何仍在使用ActiveX之类组件或“原生”功能的东西。当然，这些都该被淘汰了，但有些可能尚未被淘汰，据我所知，这些组件根本没有前途。
-- ddtaylor现在肯定有人写了MSIE 11的0day漏洞，能获取系统权限并悄无声息地安装一个IE皮肤的Chromium浏览器。如果还没人做，该有人着手了。——全体用户敬上
-- simondotauXP上最后可用的Chromium版本也有0day漏洞，所以没什么大不了的。
-- wqweto微软承诺在Windows 10 LTSC及Windows 11的Edge浏览器IE模式中支持IE 11至2032年。
-- layer8并非全球用户都能使用现代软硬件。大量学校机房仍在运行旧版软件。
-- ulrischa没错，那就用jQuery 3吧。
真疯狂——居然要求IE11内的软件使用最新版本的库。
-- halaprojQuery为升级工具投入的精力令人钦佩，这种敬佩难以言表。
-- chao-我钟爱jQuery，尤其欣赏它优雅的方法链机制——能在DOM元素对象/数组链中持续操作。
十五年前我曾为法国用户撰写jQuery教程，浏览量颇高。但愿它助力了jQuery的普及。
-- ttoinou令人惊叹的是jQuery至今仍被广泛使用。即便在现代网站中也常能发现它的踪迹(浏览器开发工具→控制台中的jQuery输出即可验证)。不仅业余网站如此，专业企业官网及其开发工具同样如此。
-- hypnot好奇：
如今取代JQ的巨无霸是什么？
我感觉它仍是事实上的行业标准？
-- KellyCriterionJQ引入的许多特性如今已成为浏览器原生功能。
-- croes或者可以用其他技术替代，比如CSS动画，只需用addClass/removeClass就能取代jQuery的动画代码。
-- bonzini整整20年！记得jQuery刚发布时，我还以为5到10年内它就会被淘汰——因为所有jQuery的功能都会内置到浏览器或成为HTML规范的一部分。
但随后谷歌、Chrome、iPhone、PWA以及无处不在的JS技术席卷而来，将网页发展引向了我当初完全无法想象的轨迹。
-- ksec十五年前我用jQuery实现的所有功能，其实十年前就能通过CSS和标准JS库完成。如今看到jQuery仍在被使用，我真心感到困惑。
如今还有什么功能是jQuery能实现而标准库几行代码做不到的吗？
-- lrvickjQuery简洁的链式语法更易读、更易记，维护起来也更愉快。重写为标准库虽易，却会因每行代码都需添加冗余模板而导致代码臃肿。
-- simondotaujQuery能用一行代码完成标准库需要数行的操作。减少代码量正是库存在的意义。
-- jampekka直到你需要升级时才发现它会反噬你
-- glemion43jQuery的核心价值在于为不一致的浏览器实现提供统一API，因此它通常能避免反噬，而非反噬你。
-- jampekka真正享受网页开发乐趣始于掌握jQuery之时。它让一切变得如此简单易用！
-- jusonchan81jQuery让混乱的生态系统稍显统一。配合CKEditor，它曾有效驯服大量网页开发者的混乱局面——直到Node.js横空出世。=3
-- Joel_Mckay好，轮到你们了，script.aculo.us 和 Mootools。
-- thm有两个框架我好久没用过了。
-- thrownaway561如果采用服务器端渲染，仅用 jQuery 或原生 JS 就够了吗？还是值得研究更复杂的 JS 前端方案？
-- t1234shtmlx[1]是当下SSR的首选库，坦白说相当不错。它能让JS在多数场景下彻底退出舞台
[1]: https://htmx.org/
-- augusto-moura没错，我现在的默认方案是 Django + Tailwind，配合 HTMX 和 Celery 处理后台任务。仅此组合就让我事半功倍。
-- 101008jQuery 曾是 JavaScript 的巅峰。
美好时光啊，很高兴它依然活跃。
-- gethly至今仍有大量网站在使用它。
-- shevy-java确实如此。尽管许多功能已被原生JavaScript和浏览器吸收，但jQuery的语法依然便捷得多。
-- marticode感觉自己老了。职业生涯初期对jQuery又爱又恨——那时我刚接触HTML5尾声，又赶上ES6新特性横行的时代。
-- zghst当浏览器间功能缺失或标准不统一时，jQuery曾极具价值。如今JS/DOM API已高度丰富、成熟且标准化，jQuery的重要性已大不如前。
https://youmightnotneedjquery.com/
诚然，原生JS的实现有时不够优雅，但绝大多数情况并不复杂。
个人认为原生JS的另一优势(除节省约30KB体积外)在于调试更便捷。例如通过开发工具定位/调试事件监听器时，原生实现更直观——复杂的jQuery事件监听器往往需要反复调试大量代码。
-- senfiaj记得当初既害怕jQuery又害怕原生JS。哎，时光飞逝啊。
难以置信它至今仍在维护。
-- NetOpWibby我也有同样经历！冒名顶替综合征真让人头疼。
-- giancarlostoro> 包含部分破坏性变更
多数变更完全合理——很多是内部清理(用户端无需修改代码)、弃用旧版浏览器等操作。
但最让我意外的是存在破坏性API变更。仍在使用jQuery的项目多为遗留项目(我自己就有几个闲置项目)。破坏性变更意味着升级过程更麻烦，而这些项目本就不值得费力升级。移除jQuery.isArray这类方法只会增加升级难度——内部实现完全可以直接调用Array.isArray，至少这样不会破坏现有代码。
这类项目在生命周期某个节点，就该接受历史定位，停止破坏与成千上万(甚至数百万！)用户项目的兼容性。只需成为一个干净利落的库，让人们能永远无需顾虑地持续使用。
-- pocketarc我不明白你的用例。既然有不想动的老项目，为什么要把依赖升级到新的大版本？你可以继续用jQuery而不必考虑升级问题。直接用3.7版，别管4版的事。
-- wartijn_修复漏洞？
最近因客户要求(安全问题)不得不将jQuery从2版升级到最新版，结果就遇到了第三方库/插件的兼容性问题。
-- Zardoz84jQuery是我最后一次感受到库能施展魔法！此后再无任何库能带来这种体验。
-- maxpert连现代原生JavaScript都不如？
-- Minor49er现在虽然接近了，但语法冗余得多：比如document.getElementById(‘theID’) vs $(‘#theID’)
-- marticode几乎每次编写JavaScript时，第一行都是const $ = (selector) => document.querySelector(selector)。我虽不像这里许多人那样怀念jQuery，但这个特定的简写确实非常实用。
为了增添趣味，还可以在顶部定义const $$ = (selector) => document.querySelectorAll(selector)。
-- majewsky const $$ = (selector) => Array.from(document.querySelectorAll(selector))
这样写更妙，因为之后就能实现：
$$(‘.myclass’).map(e => stuff)
我至今仍在使用jQuery。
-- shevy-java这个变更日志太疯狂了；它关闭了数十个在Github上开放了5年以上的issue。我猜这和这是数年来的首个新主要版本有关。
有人做过基准测试吗？看看jQuery 4和jQuery 3.7的对比？
-- Pikamander2我依然钟爱jQuery中ajax调用的简洁性
-- ulrischajQuery提供了Fetch API不具备的功能？
-- niek_pas文件上传进度。Fetch API无法在文件上传(或处理大型请求)时观察并显示进度，而jQuery通过xhr回调实现了这一功能。
我虽非前端开发者，但曾是jQuery的重度用户。可我终究难舍初心……原型框架万岁！
-- goykasi对我们这些网络诞生初期就投身Web应用开发的人而言，JQ堪称奇迹。
感谢各位！
-- bikamonki他们支持ES6模块、可信类型和CSP太棒了！清理那些已被平台替代的旧API也令人欣慰！
-- indolering关于焦点事件顺序的描述让我心跳加速，仿佛回到了十五年前的噩梦！
-- padjo在React、NextJS盛行的时代，这有什么用武之地？静态网站已有Astro等工具。即便需要简单方案，为何还要用jQuery？原生JS如今API更完善了。我是不是漏了什么？
-- admiralrohan我常开发定制化JS组件、游戏及工具，这些项目并不依赖React这类庞大框架。并非所有应用都是全页面SPA。原生JS确实进步了，但我发现自己总在编写类似JQ的小型库和工具来处理繁琐甚至基础的DOM操作，因此转回JQ后省了不少时间和麻烦。压缩后的JQ体积相当小巧，几乎不占空间。
Bootstrap等框架也使用JQ(尽管我认为他们正试图剔除此类第三方依赖，因其易引发冲突)。
我在Angular应用中也用过JQ——当标准工具无法实现复杂的即时DOM操作时，它就显得不可或缺。
-- temporallobe业余爱好者不愿学习每个新框架。有人经营小型商业网站，自2010年起就对jQuery很满意。
-- hotgeart恭喜发布新版本！虽然很久没写jQuery了，但记得在浏览器兼容性糟糕的年代它有多好用。感谢EJohn和团队持续维护这个项目。
-- thrownaway561超棒的开源库，很高兴它仍在维护！
-- alphax314无感。当年我是Mootools的忠实拥趸，目睹jQuery崛起时颇感遗憾。
如今JavaScript已进化到无需依赖jQuery的阶段，这让我欣慰。
-- hk1337本以为会迎来更彻底的变革，结果更像是内部清理工作，比如“2026年真该没人用这个了”。他们提供这个库，是为那些真心钟爱jQuery、宁愿用它也不愿用React的人准备的(这完全合理且情有可原)。
核心行为似乎没有改变，这正是人们抱怨的地方，例如https://github.blog/engineering/engineering-principles/remov…
这种语法虽然简单易写，但按我们的标准来看，并不能很好地传达意图。作者是否期望该页面存在一个或多个js-widget元素？此外，如果我们在更新页面标记时意外遗漏了js-widget类名，浏览器是否会通过异常提示告知我们出了问题？默认情况下，当初始选择器未匹配任何元素时，jQuery会静默跳过整个表达式；但对我们而言，这种行为是缺陷而非特性。
我完全赞同此观点，因为此类隐蔽缺陷曾多次让我吃尽苦头。不过我理解有些人对此并不在意。
我已确定绝不会在个人项目中使用jQuery，工作环境也绝无可能采用它(我更倾向于让框架基于数据绑定自动处理渲染)。因此这些争议与我无关。但祝jQuery及其拥趸好运。
-- g947o我是长期用户。它多年来一直服务得很好，尽管自从3.0版本后我就没怎么碰过它。很高兴看到它仍在维护中。
-- MarkdownConvert这太重要了。对于任何需要原生JavaScript无法实现的自定义交互的网站，jQuery依然是我的首选方案。
-- madduci原生JavaScript有什么做不到的？
-- nchmy嗯，或许我终于能告别2.x版本了
-- yread真希望它能支持XPath查询。
-- nashashmi从未用过jQuery的人还有必要尝试吗？
-- johanyc别被这帖里那些对jQuery念念不忘的老家伙们糊弄了——他们只是怀旧罢了。2026年根本没必要考虑用jQuery
-- modarts总体来说不需要，因为它实现的大部分功能现在都原生支持了，需要用到它的概率已经很低。
若未使用框架，它或许还能简化某些特殊场景的操作，但没必要特意为用而用。
-- thunderfork哇，干得漂亮。
-- kordlessagain哇，这很有意思。我还以为jQuery已经过时了。
我的下一个问题是：OpenAI和Anthropic会用这个来训练数据吗？如果我让Claude Code编写应用并使用jQuery，它会调用旧版本吗？除非模型重新训练到新版本？
-- sodafountan看到jQuery 4真是令人耳目一新
-- rtbruhan00jQuery是什么？我做DHTML只用Dynamic Drive
-- nprateem意外发现Zepto.js能完美替代我多数小型场景的原有方案。确实该试试jQuery精简版，之前从未研究过。
-- netbioserrorZepto！这个名字多年未闻。记不清具体经过，但我至今仍是Github上ZeptoJS组织的成员。
-- NetOpWibby我真的很喜欢这个项目！为什么不交给愿意维护的人，或者至少存档保存呢？
-- indolering向王者致敬
-- recursivedoubts现在我们需要的是从js到llm的实时日志转发。
-- kordlessagain过去十年我在小型应用中使用jQuery从未出过问题。后来我尽可能用现代JS逐步替换它，如今发现自己仅因Datatables.js依赖它才继续使用。
这段旅程很美好，衷心感谢所有参与开发的人。虽然可能看不到jQuery 5了，但这就是人生。
-- AdrianB1这名字真是久违了…
-- fourseventy还得加点 jQuery 才够味
-- tpoacher[已删除]
-- thrownawaysz我倒要反驳。那对本次发布能有什么增益？
-- pseudocomposer没人喜欢$…吗？
-- tonijnjQuery虽已升级至v4，但许多网站(尤其是WordPress)仍在使用1.11或1.12版本，仅用于实现模态框(popover)、显示/隐藏(display)或Ajax(fetch)功能。
-- gocsjessWordPress自带3.x版本，目前正计划升级至4.x
-- nchmy我指的是大量WordPress站点，而非WordPress官方本身
-- gocsjess即便迁移至ES模块后，jQuery仍显臃肿。压缩后仅4.7KB的Preact相比之下轻量得多[1]。
[0]: https://bundlephobia.com/package/jquery@4.0.0
[1]: https://bundlephobia.com/package/preact@10.28.2
-- maxloh> Preact仅需4.7KB
是否存在特殊情况，即使用虚拟 DOM 框架的开发者不会额外引入 100-200KB 的“生态系统”依赖？
虽然理论上可能存在，但我从未实际见过。倒是见过仅用 jQuery 的网站——仅需 ~27KB 就能实现丰富功能。
-- topspin我采用Preact构建极简前端，以适配小型嵌入式MCU的闪存ROM。整个前端经gzip压缩后约25KB，包含直接嵌入Preact压缩文件的SVG图像。我对引入的库及其对整体负载大小的影响极为谨慎。
最初采用jQuery构建简易前端原型，但很快突破了“压缩后总大小不超过40KB”的目标。问题在于仅靠jQuery无法满足需求——我们需要jQueryUI来辅助前端开发，否则就得自行构建类似的复杂组件。当jQuery代码量变得庞大时，Preact的优势便显而易见。当前的有效负载比jQuery原型小得多。
-- leptons看看基于Preact的Deno + Fresh。仅用Preact就能实现很多功能
-- ttoinou我做简单SPA时就这么干。纯Vue加几个自制的微型插件。
-- downsplat但jQuery功能更全面，还支持老旧浏览器。
-- onion2k官方声明仅支持Chrome最新两个版本。但考虑到他们支持IE11，这其实已经相当广泛了。
-- ZeroAurora> 包含对旧版浏览器的支持
这正是症结所在。为了2025年可能更新jQuery的10个用户支持某个浏览器，简直是疯了。
-- halapro因“臃肿”问题打破向后兼容性来缩减27kb体积，在我看来更不合逻辑。
-- mejutoco实际用户绝对不止10个。
-- shevy-java12
-- halaprojQuery 4.0ˣȻReactVueܶĿ벻jQueryݿԿ https://www.mcbinance.com
-- 匿名此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。