什么是不使用 jQuery 的经验技术原因？ [关闭]答案

【问题标题】：What are some empirical technical reasons not to use jQuery? [closed]什么是不使用 jQuery 的经验技术原因？ [关闭]
【发布时间】：2011-07-03 06:22:28
【问题描述】：

背景： 我对成天使用 HTML、Javascript 和 CSS 以及忽略工具（如 jQuery（ 或其他等效的辅助框架）和拒绝使用它们。我不是在谈论 JavaScript 大师，我是在谈论每天在战壕中的 Joe 生产开发人员。我收到了很多类似借口或个人意见的论点，我认为这些论点没有任何技术价值，我想确保我没有遗漏什么。

问题： 什么是不使用 jQuery 的经验技术原因？

我不是在寻找“像其他框架更好”的宗教或教条论点或主观意见，将 jQuery 视为问题中所有可比框架的稻草人。

【问题讨论】：

我真的觉得 jQuery 让一些人变得更笨了，说真的，他们认为 jQuery 是一种编程语言，而 javascript 是一个框架……很快他们就会问如何使用 jQuery 来添加两个数字。
如何使用 jQuery 相加 2 个数字？
var one = $("<div/>").data("add", 1); var two = $("<div>").data("add", 2); console.log(one.data("add")+two.data("add"));
我完全承认，使用 jQuery 比 vanilla JS 更好，但我认为，每个 Web 开发人员在使用 jQuery 之前都应该知道并了解它实际上做了什么，以及如何在没有 jQuery 的情况下实现他想要的。我认为许多程序员不像 jQuery 那样了解纯 JavaScript 语法，因此他们会犯常见的错误。

标签： javascript jquery frameworks

【解决方案1】：

2015 年更新：

在 2011 年的这个答案中，我谈论的是 jQuery、YUI 等库或原型。 2015 年的今天，这种推理仍然适用于 Angular、React 或 Ember 等框架。在那4年里技术进步很大，即使我看到了很多对 React 或 Angular 的偏见比我对 jQuery 或 YUI，同样的想法——尽管程度较小——仍然存在今天。

2016 年更新：

强烈推荐几天前发表的一篇文章：

Why jQuery? 作者：Michael S. Mikowski，单页 Web 应用程序一书的作者

那篇文章基本上是一个非常详细的答案题。如果在我写下面的答案时它可用 - 我肯定会引用它。

原答案：

我将回答有关 jQuery 的问题，但这些与我听到的反对使用 YUI、Prototype、Dojo、Ext 和其他少数几个的论点相同。我听到的主要论点：

文件大小，在jQuery 3.2.1 的情况下实际上是 84.6 KB - 可能比一般网站上的徽标小，并且可以从可能已经在大多数访问者的缓存。由于使用 jQuery 总是意味着您自己的 JavaScript 文件的文件大小更小，它实际上可能意味着更小下载，即使尚未在浏览器缓存中。
速度 - 编写纯 JavaScript 可能会更快，但编写 可移植 JavaScript 对大多数人来说似乎是不可能的。一个速度更快但不能在所有流行浏览器上运行的网站在现实世界中毫无用处。此外，jQuery 使用了一些非常重的优化，实际上速度非常快，并且在每个版本中都变得越来越快，因此除了琐碎的示例之外，手动编写更快的代码实际上并不是那么容易。(*)
“知识产权” - 公司害怕使用别人的代码 - 而事实上 jQuery 是开源和免费软件，从你奶奶的博客到亚马逊，从 Twitter 到银行，到处都在使用它美国，从谷歌到微软——如果他们可以使用它，那么任何公司都可以使用它。
我不记得听到过任何其他被认真使用的论点。

(*) 这是一个简单的例子：getElementById('someid') vs. jQuery('#someid')

使用 getElementById 是否更快？是的。当然，当 Blackberry 4.6 返回不再在文档中的节点时，每个人都会检查 parentNode 以捕获它，对吗？ jQuery 可以。每个人都会处理 IE 和 Opera 按名称而不是 ID 返回项目的情况，对吗？ jQuery 可以。如果您不这样做，那么您的代码就不可移植，并且您会引入很难找到的细微错误。 getElementById 是人们可能找到的最简单的例子——甚至不要让我开始讨论事件、AJAX 和 DOM...

更新：

实际上还有第四个结果是问为什么有人不想使用 jQuery。我忘了把它放在这个列表上，因为它不是真正的答案，而是任何答案的缺乏。我昨天收到的comment 提醒了我。这几乎不是被添加到列表中的“技术原因”，但可能仍然很有趣，并且实际上可能是最常见的反应。

我个人怀疑所有这些反应的根本原因是我认为是计算机科学进步的最大障碍：“我不想使用它是因为我从未使用过，因此它一定没那么重要。”

它曾经是对优化汇编器、编译器、结构化编程、高级语言、垃圾收集、面向对象编程、闭包或几乎所有我们现在认为理所当然的东西的反应——而今天它是 AJAX 库。也许有一天没有人会记得我们曾经在应用程序级别手动与原始 DOM API 交互，就像现在没有人记得我们曾经使用 raw, unadorned, inscrutable hexadecimal numbers 编写程序一样。

【讨论】：

企业中有太多人不了解开源许可。他们知道 GPL 具有传染性，并且必须在所有可能进入产品的软件中避免使用。然后，他们中的许多人担心 GPL 感染，禁止在业务的任何地方使用开源，从而确保安全。
这就是为什么我总是说微软使用 jQuery，这是地球上最后一家冒着使用任何会威胁到他们宝贵知识产权的东西的公司。
这是一个非常高质量的答案，非常感谢您花时间写出来！
你忘了真正的主要原因是性能。 jQuery 在 DOM 操作方面与原生 JS 相比非常慢——这是众所周知的事实。它在小型应用程序中并不明显，但它确实为大型 Web 应用程序中的交互增加了明显的抖动。另外，您对文件大小的看法是错误的。我很少会编写如此多的原生 JS，以至于它超过了所有 jQuery 库和我的应用程序中的代码量。你有偏见。 jQuery 在构建大多数网站和 Web 应用程序原型时很有用，但也有不使用它的情况：此外，nodeJS 中没有 DOM。
在易于理解的十六进制数字之前有plugboards。截至 2010 年 7 月，仍有至少一部作品IBM 402

【解决方案2】：

jQuery 以 DOM 为中心的范式表达一切，这可能会产生误导，并且不需要在应用程序模式中表达任何东西。

许多开发人员最终使用这种以 DOM 为中心的模式将自己编程到了一个角落，最终意识到他们没有创建任何可扩展或可重用的东西。

Rebecca Murphey 有一篇关于她自己切换到 Dojo from jQuery 的精彩文章 - 博客文章更多地是关于为什么不 jQuery 与 为什么 Dojo。

【讨论】：

关于以 DOM 为中心的范例的有趣点，但我的问题包括不想使用 任何东西，包括 Dojo。
请注意，如果您有时间，您可能会发现 Rebecca 的 jsconfeu 演示很有价值（并且可能与您当前的兴趣更相关）：jsconfeu.blip.tv/file/4308069
我引用了她的博客文章，因为她谈到了为什么不 jQuery 和她为什么选择Dojo。要点是我上面详述的原因。就个人而言，我认为现在不使用框架是出于无知、骄傲，或两者兼而有之。
感谢您提供的附加链接，它看起来是一个经过深思熟虑的文章，我一定会阅读它

【解决方案3】：

不使用框架的一个原因 - 这是一个极端的情况 - 是为另一个网站编写可嵌入代码时，例如横幅。任意插入一些复杂的库或另一个会污染名称空间并可能破坏其他人的站点。不是说我不会让一些广告商去尝试，吸池塘的渣滓，但我离题了......

我不赞成在框架已经存在且具有同等能力的情况下添加框架。我经常看到它，这是我最讨厌的，我认为这是毫无根据的膨胀。这完全是另一个问题。

除此之外，我想不出有什么理由不这样做。

【讨论】：

这是一个没有人想到的好答案
这个。只是刚刚遇到一个页面，我必须对 JQuery 1.4.4 作为 JS 标记加载的位置进行一些维护，而 JQuery 1.3.x 使用 Google 的 CDN 和替代命名空间加载（因此 $() 方法变成了 $jq 之类的东西())。
stackoverflow.com/questions/693174/… => 不仅在将代码嵌入其他网站时，而且在其他支持 javascript 的引擎中。

【解决方案4】：

filesize - 但实际上，除此之外，它绝对是跨平台 JavaScript 和浏览器差异的天赐之物。你必须有一些很好的理由不希望它出现在你的工具包中（或者成为一个原教旨主义的开发者白痴）。

【讨论】：

是的，这些很好的理由就是我要找的……
如果我可以为您的 “原教旨主义开发者白痴” 评论添加一些平衡，请考虑一下也有很多 原教旨主义 jQuery 白痴 的事实。那些强烈推荐在任何情况下都使用 jQuery 的人，包括当你只需要 5 行 javascript 时。
我不能赞成这个。压缩后的 jQuery 为 29kb - 比大多数图像小很多 - 如果从 CDN 提供（参见 docs.jquery.com/Downloading_jQuery），那么它可以很好地缓存。
没有什么比一个好的、非常主观的意见来激发 cmets :) - 对于那些只使用 jQuery 来简化选择器的人，他们也可以尝试它正在使用的选择器引擎，Sizzle -小得多 - sizzlejs.com
@jpea：品脱会做到这一点。 ;o) 使用 Sizzle 的要点。

【解决方案5】：

他们无法证明文件大小是合理的（即使它可能小于不使用提供的抽象的脚本）。
他们不想依赖第三方工具。
他们的企业不想运行任何库（无论出于何种原因）。
他们的企业不想运行任何不是其员工编写的 JavaScript 代码。

【讨论】：

其中一些观点让我想起了 5 年前我对这些框架的看法，当时它们还很年轻。那时我还没有足够的了解，无法理解他们为编码人员节省了多少必须经常处理的事情，我自然地想，“为什么不做我需要做的事情，我自己呢？”我想知道，您认为那里的一些公司在 5 年后仍然这样认为的可能性有多大？在大多数情况下，除非文件大小或 IP 真的是一个问题，否则我会说他们对自己造成了严重的伤害。
@Ken Franqueiro 我在 Stack Overflow 上看到过。有人问不使用jQuery做某事，然后有人问为什么不用jQuery？，提问者回答我们公司不能使用任何第三方库。也许他们为 NASA 工作，而新的太空探索机器使用 JavaScript（嘿，它是无处不在：P）
是时候找一份新工作了！

【解决方案6】：

学习：实际编写所有代码并了解更多信息。（而不是使用预编码的东西）
大小： jQuery 有很多你可能不需要的功能，如果不使用，为什么还要让用户下载这么多代码？
替代方案：目前，有几十个功能更强大、结构良好的 Web 框架。
灵活性：虽然 jQuery 非常灵活，但您可能需要它不提供的东西。

【讨论】：

“实际编写所有代码，并了解更多信息。” - 这适用于学生，但如果你是必须为 Massive Inc 的新网站做 JS 的人，你必须能够对使用准系统 JS 的选择负责，你自己的框架总是试图模仿一些现有框架，并有洞察力和经验来预防和修复 JQuery 和类似库已经存在的浏览器兼容性错误。有关这方面的一个很好的例子，请参阅 rsp 的答案。

【解决方案7】：

无论如何，我喜欢jQuery，但有一些理由不使用jQuery：

下载大小/带宽：未压缩的 jQuery 1.5 现在超过 200K，因为库的大小太大而无法证明其好处。
性能：编写原生 JS 总是比在库中抽象它更快。
增加了复杂性：许多人会下载整个 jQuery 库，而实际上他们只需要其中的一些简洁功能。
应用程序依赖项：引入依赖项总是有问题。如果 jQuery 有 bug，你可以调试和编辑文件，但是稍后升级会引入问题。你可以留下这个错误，但现在你依赖于 jQuery 的时间表来修复，而不是你自己的。

【讨论】：

当然，对于生产，您应该始终使用压缩和 gzip 压缩的版本，在撰写本文时为 29 KB。其次，虽然抽象确实会降低性能，但在许多情况下，我更信任 jQuery 开发人员而不是我自己，类似情况；在我继承的应用程序中，本土排序（这并不是什么可怕的事情）比使用 tablesorter jQuery 插件慢一个数量级。
当然。我喜欢 jQuery，但对于某些人来说，这是他们的论点。
Google 通过其 CDN 提供 jQuery 意味着如果您使用该版本，它很可能已经在用户本地缓存中。

【解决方案8】：

因为很多时候它只是不必要的。如果我想做的只是验证一些输入，或者突出显示一些字段，那么编写简单的 javascript / dom 代码同样容易。而jQuery在这种简单的情况下并没有真正的帮助，所以问题应该是为什么要使用它？

显然在很多情况下它非常有用，但有时人们似乎也无缘无故地使用它。

【讨论】：

实际上，即使在这种微不足道的情况下，JS 框架也会有所帮助。使用 getElementById （请参阅 rsp 的答案）之类的东西防止跨浏览器错误，使用 JQuery 验证插件等即时访问预构建的验证器。使用 JQuery 会减少开发时间，而且开发时间很昂贵。特别是如果“验证某些输入”随着时间的推移而增长到包括站点范围的 JS 内容。

【解决方案9】：

我更喜欢使用 jquery 进行 dom 操作或遍历 dom ，使用 jquery 真的很容易。此外，使用 jquery 或其他框架附加事件或事件委托非常容易，否则您必须为 IE 或非 IE 浏览器等编写自定义事件附件。

但是当您使用 $.each 而不是 vanilla JS for 和 array.push() 时，它会降低性能... 其他问题，例如如果您绑定一个事件并在没有取消绑定的情况下将其删除，它将导致内存泄漏......

我的结论是只使用任何框架进行复杂的 dom 操作，其余使用 vanilla JS

【讨论】：

【解决方案10】：

为什么不使用 jQuery？

我想不出在 jQuery 上使用 vanilla JavaScript 的好借口（除了学习新东西的恐吓因素），但由于哲学上的差异，有些人更喜欢其他 JavaScript 框架（比如优秀的MooTools）他们之间。

有些人根本不喜欢 jQuery 的 DSL-ish 语法，但他们认识到使用强大的 JavaScript 框架的重要性。

就个人而言，我喜欢 jQuery，但我认识一些使用其他框架并且效率不低的人。

【讨论】：

是的，我知道这一点，其他人不知道使用健壮的 JavaScript 框架的重要性，他们有什么技术上的正当理由吗？跨度>
@fuzzy：在选择工具时，情感原因远比技术原因重要，除非您是少数有责任找到最佳工作方式的技术架构师之一。
@Michael - 我所处的位置我不关心这些类型的原因，我关心我的员工的生产力，就像我不明白为什么有些人坚持使用在 Windows 上用记事本编写自己的所有 Java 代码，使用专用的 Java IDE 总是会更有效率。我关心人们的工作效率，我只是想确保我不会错过一些不坚持使用像 jQuery 这样的东西的正当技术理由。
@fuzzy lollipop：你明白javascript库只是预先编写的javascript代码，对吧？
...像文件大小这样的原因是主观的。一个人认为太大的东西可能被另一个人认为是完全可以接受的。看看我在说什么？