2015 年更新：

在 2011 年的这个答案中，我谈论的是 jQuery、YUI 或 Prototype 之类的库。到了 2015 年，这种推理仍然适用于 Angular、React 或 Ember 等框架。在这 4 年里，技术取得了巨大的进步，尽管我看到的对 React 或 Angular 的偏见比对 jQuery 或 YUI 的偏见少得多，但同样的想法——尽管程度较轻——今天仍然存在。

2016 年更新：

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

• 为什么是jQuery？作者：Michael S. Mikowski，Single Page Web Applications一书的作者

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

原答案：

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

1. 文件大小，实际上在jQuery 3.2.1 的情况下为 84.6 KB - 可能比一般网站上的徽标小，并且可以从 Google 的 CDN 提供，它可能已经在大多数访问者的缓存中。由于使用 jQuery 总是意味着您自己的 JavaScript 文件的文件大小更小，因此它实际上可能意味着更小的下载，即使尚未在浏览器缓存中。

2. 速度- 编写纯 JavaScript 可能会更快，但是对于大多数人来说，编写可移植的JavaScript 似乎是不可能的。一个速度更快但不适用于所有流行浏览器的网站在现实世界中毫无用处。此外，jQuery 使用了一些非常繁重的优化，实际上非常快，并且在每次发布时都会变得更快，因此除了琐碎的示例之外，手动编写更快的代码实际上并不容易。(*)

3. “知识产权” ——一家公司害怕使用别人的代码——而事实上 jQuery 是开源和免费软件，从你奶奶的博客到亚马逊，从 Twitter 到美国银行，从谷歌到微软——如果他们可以的话使用它然后任何公司都可以使用它。

4. 我不记得听到任何其他被认真使用的论点。

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

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

更新：

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

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

它曾经是对优化汇编器、编译器、结构化编程、高级语言、垃圾收集、面向对象编程、闭包或我们现在认为理所当然的几乎所有东西的react——今天它是 AJAX 库。也许有一天没有人会记得我们曾经在应用程序级别上手动与原始 DOM API 交互，就像现在没有人记得我们曾经使用原始的、朴素的、难以理解的十六进制数字编写程序。

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

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

Rebecca Murphey 有一篇关于她自己从 jQuery转向Dojo的精彩文章 - 博客文章更多地是关于为什么不使用jQuery 与为什么使用Dojo。

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

当一个框架已经存在并且同样有能力时，我不赞成添加一个框架。我经常看到它，这是我讨厌的宠物，我认为它是毫无根据的膨胀。那完全是另一个问题。

除此之外，我想不出不这样做的正当理由。

文件大小 - 但实际上，除此之外，它是跨平台 javascript 和浏览器差异的绝对天赐之物。您必须有一些非常好的理由不想在您的工具包中使用它（或者成为一个原教旨主义的开发人员白痴）。

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