首页 > 娱乐幽默 想念 jQuery jQuery刚推出时我拒绝使用它，因为觉得额外代码对网站负担太重。如今想来都觉得后怕。 💬 63 条评论 | javascript | 2025-12-10 共有 63 条讨论 我真的很想有天尝试WebAssembly 回复 我尝试WebAssembly时发现它特别适合处理大量数值变量，因为能用整数等占用更少内存的数据类型。但涉及字符串时，直接用JavaScript反而更简单。或许两者结合才是上策。 回复 目前还在开发中。Dioxus的亚秒级响应试图让开发体验接近普通TypeScript Web框架，但尚未完全实现。不过两者性能相当接近(不计UTF-8转UTF-16的开销)，如果你足够喜欢Rust这门语言，或许会享受开发过程，但它可能还不适合生产环境。 回复 它存在若干缺点，但最大的问题在于：你必须在实际代码之外额外部署整个WebAssembly标准库实现，还得加上运行所需的JavaScript。这本质上就是现代版的Java小程序(实际上更糟糕，因为Java小程序至少会使用用户电脑已安装的Java环境)。 回复 “更好”是指性能？还是易用性？:) 另外方便的话，能否透露你在应用中将Wasm部署在哪个环节？我正尝试理解Wasm的适用场景。 祝你愉快 🙂 回复 性能更优，因为它更贴近硬件且抽象层更少。易用性取决于具体场景——对我而言计算物理模拟时较为复杂，但运行起来相当简单：我用Emscripten编译wasm，代码用C++编写。 若你的应用需要webgl和/或webgpu，它就是绝佳选择 回复 听着，我曾经很喜欢jQuery。它在那个时代确实是款好工具。但如今VanillaJS才是正道。 回复 我记得有个阶段，所有人都痛恨jQuery，争相从项目中移除jQuery依赖，只用原生JavaScript替代。 回复 这完全取决于你构建什么。 对于需要基本交互和表单验证的网站，当然可以。 但如果是Web应用，我可不想重新实现并维护那些成熟框架里已有的功能。 回复 好奇is-odd算不算成熟框架 回复 这选择真奇怪。你为何要举微库的例子，而不是 React、Angular、Vue、Next、D3、TypeScript、Express、Webpack、Vite、Axios、Jest 或 date-fns 之类？ is-odd 可能十行代码就能实现，但组件框架或与其良好集成的路由库可没这么简单。 回复 正因这个微库完美诠释了JS生态的弊病。它不仅真实存在且被npm收录，更拥有数百万次安装量。当然，重复造轮子确实是另一大罪过。但请重读你自己的评论，数数你列举了多少功能完全重叠的框架。 回复 针对相同或相似的整体用例存在多种解决方案，这并非JS独有现象。 JavaScript不像Java或C#那样拥有单一核心所有者，因此绝大多数技术都由社区开发。某些场景需要不同方案(React、Angular、Vue)，而随着标准新增特性，整体更优的解决方案也会应运而生(Momentjs→date-fns，以及lodash和jQuery事实上被淘汰的趋势)。 框架与最佳实践每月更迭的现象，在十年前ES6标准问世、语言应用迎来爆发期时确实存在，但人们至今仍固守这种认知。 is-odd包的批评或许有其道理，但被过度夸大了。 回复 兄弟，我认为若他们真要构建需要可复用性与快速扩展的大型应用… 我认为路由库就是典型例子——谁愿意每次都从头重构？试着自己从零构建它，确保能在任何复杂Web应用场景下运行，你就会明白。 兄弟，我同意你的观点，这取决于你构建什么项目。 回复 提到这个真是个奇怪的选择 因为这恰恰是JS“不愿重构和维护已有功能”理念演变成疯狂的绝佳例证。随便看个小项目的package-lock.json文件，动辄上万行。那个检测奇数的小包每周下载量高达50万次，靠。而这堆无用垃圾居然还依赖着is-number库…JS生态系统简直烂透了。 回复 你能想象用纯净的vanilla js、html和css构建功能复杂的现代网页应用吗？想复用页面组件就得反复重写HTML代码，每个功能都要对应一堆意大利面式的JS文件。听着简直像噩梦 回复 听起来你当年根本没真正开发过大型JavaScript应用。纯JavaScript完全可以组织成封装良好的“类”，拆分成可复用的独立文件。 当然你也可以直接把一堆垃圾代码塞进HTML的script标签里草草了事——这大概就是大多数人的做法。 回复 我完全做得到。因为维护自己按规范编写的代码——尤其是保持一致性的代码——远比追查依赖模块的意外行为轻松得多。这种优势在长期开发中，轻松抵消了前期投入的额外精力。 前提是你确实建立了良好的代码规范和开发策略。你应该有这些吧？ 回复 说得对。一个小应用程序，文件夹突然比项目本身还重。 回复 代码微不足道，文件夹却像个行李箱 回复 如今我们使用jQuery的90%理由都体现在DOM API上…若想仅凭jQuery构建Web应用，尽管放手去做。重新认识我们当初为何要开发框架吧。 回复 他们只想让技术停滞。他们执着于jQuery，只因熟悉它，它勉强能完成任务，且不愿学习新事物。他们漠视框架诞生的初衷，甚至认为这根本是个笑话。 回复 我们想终结的不是技术本身。我们反对的是JavaScript的疯狂。别敢用“技术”这个高尚词汇来形容这堆糟糕的代码。 回复 自从jsx出现后浏览器已经进步了 回复 谁在把node_modules发给客户？ 回复 这就是我用次日达空运所有node_modules的原因，延迟虽然垃圾但都能瞬间加载 回复 如今99%的node_modules都是构建和代码检查测试库。如果停止这些操作，node_modules绝对能控制在合理大小！ 回复 听说过“vendoring”这个术语吗？ 回复 那些想当自己供应链载体的人啊 回复 其实不少东西最终还是会被纳入最终版本。虽非全部，但数量可观 回复 不过打包质量取决于开发者——笑到最后的才是赢家 回复 没人。制造梗图的人根本不写Web应用。这只对那些懒得做原生应用的Electron开发者有意义。 回复 其他语言就不同吗？区别仅在于npm将依赖项保存在本地，所以你能看到它们。但maven、pip、nuget等工具同样会下载依赖项，而庞大的框架在任何系统中都必然占用等量的磁盘空间。 回复 Maven/Gradle占空间少，因为jar包是压缩的。 回复 说的是Maven。Gradle是构建工具而非依赖库(Maven恰好兼具两者功能)。 回复 Maven真是个麻烦精 回复 发现Ant用户了 回复 宁可选NuGet+更优秀的Java 回复 Kotlin > C# > Java，有异议尽管来辩 回复 Kotlin确实更优，你说得对。有天想试试 回复 但愿它能编译成.NET/mono版本 回复 作为构建工具：是 作为工件仓库：否 回复 典型Python应用的依赖树比JS小3..5倍。 回复 jQuery刚推出时我拒绝使用它，因为觉得额外代码对网站负担太重。如今想来都觉得后怕。 回复 希望你明白这有多荒谬。当年网络连接不仅慢得多，而且如果你真打算把整个node_modules文件夹发给客户，最好先好好研究一下构建管道。通常99%的依赖关系树属于开发依赖项，这些本就不该出现在生产环境中。况且如今用现代框架构建的生产应用体量，往往比当年jQuery应用还要小(因为jQuery不支持树摇动优化)。 回复 整个子版块充斥着自视甚高的后端开发者。 回复 倒也不尽然，多数是学生和年轻人。这个版块本质上就是个“哈哈js类型强制真搞笑”的漫长梗库。 回复 谁能帮我创建一个JavaScript标准库，直接打包到浏览器和运行时框架里？ 选取最常用的1000个包，稍加整理，就能成为标准库。 回复 JS其实已有标准库的等效方案。 回复 这正是那位用户的要求。去创建一个吧。 回复 2011年：https://xkcd.com/927/ 回复 npm <=6 版本的 Node 模块应减少依赖其他 Node 模块的数量。务必实现。 回复 Rust 仓库 回复 为什么整个评论区都在讨论 jQuery？这梗图根本没提到它啊？ 编辑：忽略，没看标题 回复 当然啦，既然能把所有代码塞进一个文件发给客户端，谁还需要拆分呢。 回复 笑死但说得对😭 文件夹里塞太多文件和子文件夹了 回复 我有个Rails应用，用几个Node包来拼接压缩CSS。node_modules居然4G！搞什么鬼？！ 回复 几乎所有Rust应用都是这样 回复 能用vibecode吗 回复 若讨论不使用Node模块的Web应用，构建大规模Web应用时需考量代码复用性、渲染性能及开发效率。 回复 听我说伙计们，我们将打造一个比jQuery更优秀的全新框架，让JavaScript重焕辉煌。 回复 公平地说，原生JavaScript近年进步显著。如今我几乎找不到使用其他方案的理由了。 回复 我敢打赌，对程序员来说这很有趣 回复 发表回复 取消回复您的邮箱地址不会被公开。 必填项已用 * 标注评论 * 显示名称 * 邮箱 * 网站 你也许感兴趣的： Oracle，是时候解放JavaScript了 JavaScript中的错误链：借助Error.cause实现更清晰的调试 使用 setHTML() 方法消毒HTML 可以用 CSS 实现这些，不再需要 JavaScript JavaScript 的美好未来不会实现 Bun Install 比 npm 快 7 倍，Why? 魔方交互式动画、可编程JavaScript工具库：Roofpig 编程界的丰田卡罗拉 Google V8：我们如何让 JSON.stringify 的速度提升超过两倍 🚦 JavaScript Signals 标准提案🚦
目前还在开发中。Dioxus的亚秒级响应试图让开发体验接近普通TypeScript Web框架，但尚未完全实现。不过两者性能相当接近(不计UTF-8转UTF-16的开销)，如果你足够喜欢Rust这门语言，或许会享受开发过程，但它可能还不适合生产环境。 回复
它存在若干缺点，但最大的问题在于：你必须在实际代码之外额外部署整个WebAssembly标准库实现，还得加上运行所需的JavaScript。这本质上就是现代版的Java小程序(实际上更糟糕，因为Java小程序至少会使用用户电脑已安装的Java环境)。 回复
性能更优，因为它更贴近硬件且抽象层更少。易用性取决于具体场景——对我而言计算物理模拟时较为复杂，但运行起来相当简单：我用Emscripten编译wasm，代码用C++编写。 若你的应用需要webgl和/或webgpu，它就是绝佳选择 回复
这选择真奇怪。你为何要举微库的例子，而不是 React、Angular、Vue、Next、D3、TypeScript、Express、Webpack、Vite、Axios、Jest 或 date-fns 之类？ is-odd 可能十行代码就能实现，但组件框架或与其良好集成的路由库可没这么简单。 回复
针对相同或相似的整体用例存在多种解决方案，这并非JS独有现象。 JavaScript不像Java或C#那样拥有单一核心所有者，因此绝大多数技术都由社区开发。某些场景需要不同方案(React、Angular、Vue)，而随着标准新增特性，整体更优的解决方案也会应运而生(Momentjs→date-fns，以及lodash和jQuery事实上被淘汰的趋势)。 框架与最佳实践每月更迭的现象，在十年前ES6标准问世、语言应用迎来爆发期时确实存在，但人们至今仍固守这种认知。 is-odd包的批评或许有其道理，但被过度夸大了。 回复
兄弟，我认为若他们真要构建需要可复用性与快速扩展的大型应用… 我认为路由库就是典型例子——谁愿意每次都从头重构？试着自己从零构建它，确保能在任何复杂Web应用场景下运行，你就会明白。 兄弟，我同意你的观点，这取决于你构建什么项目。 回复
提到这个真是个奇怪的选择 因为这恰恰是JS“不愿重构和维护已有功能”理念演变成疯狂的绝佳例证。随便看个小项目的package-lock.json文件，动辄上万行。那个检测奇数的小包每周下载量高达50万次，靠。而这堆无用垃圾居然还依赖着is-number库…JS生态系统简直烂透了。 回复
听起来你当年根本没真正开发过大型JavaScript应用。纯JavaScript完全可以组织成封装良好的“类”，拆分成可复用的独立文件。 当然你也可以直接把一堆垃圾代码塞进HTML的script标签里草草了事——这大概就是大多数人的做法。 回复
我完全做得到。因为维护自己按规范编写的代码——尤其是保持一致性的代码——远比追查依赖模块的意外行为轻松得多。这种优势在长期开发中，轻松抵消了前期投入的额外精力。 前提是你确实建立了良好的代码规范和开发策略。你应该有这些吧？ 回复
希望你明白这有多荒谬。当年网络连接不仅慢得多，而且如果你真打算把整个node_modules文件夹发给客户，最好先好好研究一下构建管道。通常99%的依赖关系树属于开发依赖项，这些本就不该出现在生产环境中。况且如今用现代框架构建的生产应用体量，往往比当年jQuery应用还要小(因为jQuery不支持树摇动优化)。 回复
我真的很想有天尝试WebAssembly
我尝试WebAssembly时发现它特别适合处理大量数值变量，因为能用整数等占用更少内存的数据类型。但涉及字符串时，直接用JavaScript反而更简单。或许两者结合才是上策。
目前还在开发中。Dioxus的亚秒级响应试图让开发体验接近普通TypeScript Web框架，但尚未完全实现。不过两者性能相当接近(不计UTF-8转UTF-16的开销)，如果你足够喜欢Rust这门语言，或许会享受开发过程，但它可能还不适合生产环境。
它存在若干缺点，但最大的问题在于：你必须在实际代码之外额外部署整个WebAssembly标准库实现，还得加上运行所需的JavaScript。这本质上就是现代版的Java小程序(实际上更糟糕，因为Java小程序至少会使用用户电脑已安装的Java环境)。
“更好”是指性能？还是易用性？:) 另外方便的话，能否透露你在应用中将Wasm部署在哪个环节？我正尝试理解Wasm的适用场景。
祝你愉快 🙂
性能更优，因为它更贴近硬件且抽象层更少。易用性取决于具体场景——对我而言计算物理模拟时较为复杂，但运行起来相当简单：我用Emscripten编译wasm，代码用C++编写。
若你的应用需要webgl和/或webgpu，它就是绝佳选择
听着，我曾经很喜欢jQuery。它在那个时代确实是款好工具。但如今VanillaJS才是正道。
我记得有个阶段，所有人都痛恨jQuery，争相从项目中移除jQuery依赖，只用原生JavaScript替代。
这完全取决于你构建什么。
对于需要基本交互和表单验证的网站，当然可以。
但如果是Web应用，我可不想重新实现并维护那些成熟框架里已有的功能。
好奇is-odd算不算成熟框架
这选择真奇怪。你为何要举微库的例子，而不是 React、Angular、Vue、Next、D3、TypeScript、Express、Webpack、Vite、Axios、Jest 或 date-fns 之类？
is-odd 可能十行代码就能实现，但组件框架或与其良好集成的路由库可没这么简单。
正因这个微库完美诠释了JS生态的弊病。它不仅真实存在且被npm收录，更拥有数百万次安装量。当然，重复造轮子确实是另一大罪过。但请重读你自己的评论，数数你列举了多少功能完全重叠的框架。
针对相同或相似的整体用例存在多种解决方案，这并非JS独有现象。
JavaScript不像Java或C#那样拥有单一核心所有者，因此绝大多数技术都由社区开发。某些场景需要不同方案(React、Angular、Vue)，而随着标准新增特性，整体更优的解决方案也会应运而生(Momentjs→date-fns，以及lodash和jQuery事实上被淘汰的趋势)。
框架与最佳实践每月更迭的现象，在十年前ES6标准问世、语言应用迎来爆发期时确实存在，但人们至今仍固守这种认知。
is-odd包的批评或许有其道理，但被过度夸大了。
兄弟，我认为若他们真要构建需要可复用性与快速扩展的大型应用… 我认为路由库就是典型例子——谁愿意每次都从头重构？试着自己从零构建它，确保能在任何复杂Web应用场景下运行，你就会明白。
兄弟，我同意你的观点，这取决于你构建什么项目。
提到这个真是个奇怪的选择
因为这恰恰是JS“不愿重构和维护已有功能”理念演变成疯狂的绝佳例证。随便看个小项目的package-lock.json文件，动辄上万行。那个检测奇数的小包每周下载量高达50万次，靠。而这堆无用垃圾居然还依赖着is-number库…JS生态系统简直烂透了。
你能想象用纯净的vanilla js、html和css构建功能复杂的现代网页应用吗？想复用页面组件就得反复重写HTML代码，每个功能都要对应一堆意大利面式的JS文件。听着简直像噩梦
听起来你当年根本没真正开发过大型JavaScript应用。纯JavaScript完全可以组织成封装良好的“类”，拆分成可复用的独立文件。
当然你也可以直接把一堆垃圾代码塞进HTML的script标签里草草了事——这大概就是大多数人的做法。
我完全做得到。因为维护自己按规范编写的代码——尤其是保持一致性的代码——远比追查依赖模块的意外行为轻松得多。这种优势在长期开发中，轻松抵消了前期投入的额外精力。
前提是你确实建立了良好的代码规范和开发策略。你应该有这些吧？
说得对。一个小应用程序，文件夹突然比项目本身还重。
代码微不足道，文件夹却像个行李箱
如今我们使用jQuery的90%理由都体现在DOM API上…若想仅凭jQuery构建Web应用，尽管放手去做。重新认识我们当初为何要开发框架吧。
他们只想让技术停滞。他们执着于jQuery，只因熟悉它，它勉强能完成任务，且不愿学习新事物。他们漠视框架诞生的初衷，甚至认为这根本是个笑话。
我们想终结的不是技术本身。我们反对的是JavaScript的疯狂。别敢用“技术”这个高尚词汇来形容这堆糟糕的代码。
自从jsx出现后浏览器已经进步了
谁在把node_modules发给客户？
这就是我用次日达空运所有node_modules的原因，延迟虽然垃圾但都能瞬间加载
如今99%的node_modules都是构建和代码检查测试库。如果停止这些操作，node_modules绝对能控制在合理大小！
听说过“vendoring”这个术语吗？
那些想当自己供应链载体的人啊
其实不少东西最终还是会被纳入最终版本。虽非全部，但数量可观
不过打包质量取决于开发者——笑到最后的才是赢家
没人。制造梗图的人根本不写Web应用。这只对那些懒得做原生应用的Electron开发者有意义。
其他语言就不同吗？区别仅在于npm将依赖项保存在本地，所以你能看到它们。但maven、pip、nuget等工具同样会下载依赖项，而庞大的框架在任何系统中都必然占用等量的磁盘空间。
Maven/Gradle占空间少，因为jar包是压缩的。
说的是Maven。Gradle是构建工具而非依赖库(Maven恰好兼具两者功能)。
Maven真是个麻烦精
发现Ant用户了
宁可选NuGet+更优秀的Java
Kotlin > C# > Java，有异议尽管来辩
Kotlin确实更优，你说得对。有天想试试
但愿它能编译成.NET/mono版本
作为构建工具：是
作为工件仓库：否
典型Python应用的依赖树比JS小3..5倍。
jQuery刚推出时我拒绝使用它，因为觉得额外代码对网站负担太重。如今想来都觉得后怕。
希望你明白这有多荒谬。当年网络连接不仅慢得多，而且如果你真打算把整个node_modules文件夹发给客户，最好先好好研究一下构建管道。通常99%的依赖关系树属于开发依赖项，这些本就不该出现在生产环境中。况且如今用现代框架构建的生产应用体量，往往比当年jQuery应用还要小(因为jQuery不支持树摇动优化)。
整个子版块充斥着自视甚高的后端开发者。
倒也不尽然，多数是学生和年轻人。这个版块本质上就是个“哈哈js类型强制真搞笑”的漫长梗库。
谁能帮我创建一个JavaScript标准库，直接打包到浏览器和运行时框架里？
选取最常用的1000个包，稍加整理，就能成为标准库。
JS其实已有标准库的等效方案。
这正是那位用户的要求。去创建一个吧。
2011年：https://xkcd.com/927/
npm <=6 版本的 Node 模块应减少依赖其他 Node 模块的数量。务必实现。
Rust 仓库
为什么整个评论区都在讨论 jQuery？这梗图根本没提到它啊？
编辑：忽略，没看标题
当然啦，既然能把所有代码塞进一个文件发给客户端，谁还需要拆分呢。
笑死但说得对😭 文件夹里塞太多文件和子文件夹了
我有个Rails应用，用几个Node包来拼接压缩CSS。node_modules居然4G！搞什么鬼？！
几乎所有Rust应用都是这样
能用vibecode吗
若讨论不使用Node模块的Web应用，构建大规模Web应用时需考量代码复用性、渲染性能及开发效率。
听我说伙计们，我们将打造一个比jQuery更优秀的全新框架，让JavaScript重焕辉煌。
公平地说，原生JavaScript近年进步显著。如今我几乎找不到使用其他方案的理由了。
我敢打赌，对程序员来说这很有趣