不使用jQuery的一些经验性技术原因是什么？[关闭]

上下文： 我为一整天整天攻击HTML，Javascript和CSS而忽略诸如jQuery（或其他等效的辅助框架）之类的工具而拒绝使用它们的前端开发人员感到惊讶。我不是在谈论JavaScript专家，而是在每天都在谈论Joe生产开发人员。我有很多论点，例如借口或个人观点，我认为这些论点没有任何技术价值，我想确保自己没有遗漏任何东西。

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

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

2015年更新：

在2011年的这个答案中，我谈论的是jQuery，YUI或Prototype之类的库。在2015年的今天，推理仍然适用于Angular，React或Ember之类的框架。在那4年中，这项技术取得了长足的进步，尽管我对React或Angular的偏见要比对jQuery或YUI的偏见要少得多，但今天仍然存在相同的想法-尽管程度较小。

2016年更新：

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

• 为什么使用jQuery？单页Web应用程序书的作者Michael S. Mikowski

该文章基本上是对该问题的非常详细的答案。当我在下面编写答案时，如果该功能可用-我肯定会引用它。

原始答案：

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

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

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

3. “知识产权” -一家公司不敢使用别人的代码-实际上jQuery是开源和免费软件，从您祖母的博客到亚马逊，从Twitter到美国银行，从Google到Microsoft到处都可以使用。使用它，那么任何公司都可以使用它。

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

（*）这是一个简单的示例：getElementById（'someid'）与jQuery（'＃someid'）

使用getElementById更快吗？是。当然，每个人都总是检查parentNode以在Blackberry 4.6返回文档中不再存在的节点时捕获，对吗？jQuery确实如此。每个人都处理IE和Opera通过名称而不是ID返回项目的情况，对吗？jQuery确实如此。如果您不这样做，那么您的代码将无法移植，并且会引入难以发现的细微错误。getElementById是可能找到的最简单的示例-甚至不让我开始了解事件，AJAX和DOM ...

更新：

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

但是，我个人认为这是所有这些反应的主要原因，也是我认为这是计算机科学发展的最大障碍：“我不想使用它，因为我从未这样做，因此必须没那么重要。”

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

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

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

丽贝卡·穆菲（Rebecca Murphey）撰写了一篇很好的文章，讲述了自己从jQuery切换到Dojo的问题-博客文章更多地讨论了为什么不使用jQuery与为什么使用Dojo。

不使用框架的一个原因-这是一个极端的情况-是在为另一个网站（例如横幅）编写可嵌入代码时。任意插入某个复杂的库或另一个库将污染名称空间，并可能破坏其他人的站点。并不是说我不会放任一些广告客户去尝试，这是烂摊子，但我离题了……

我不赞成在已有框架且功能相同的情况下添加框架。我经常看到这一切，这是我的宠物恨，我认为这是毫无根据的膨胀。这完全是另一个问题。

除此之外，我无法想到没有理由的理由。

文件大小-但实际上，除此之外，跨平台的javascript和浏览器差异绝对是天赐之物。您将有一些非常好的理由不希望它出现在您的工具箱中（或者成为一个基础主义者的白痴）。

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

• 学习：实际编写所有内容，并了解更多信息。（而不是使用预编码的东西）
• 大小： jQuery具有您可能不需要的大量功能，如果不使用它，为什么要让用户下载太多代码？
• 替代方案：在这一点上，有许多更强大，结构合理的Web框架。
• 灵活性：尽管jQuery非常灵活，但是您可能需要它没有提供的功能。

无论如何，我喜欢jQuery，但是有一些不使用jQuery的原因：

1. 下载大小/带宽：jQuery 1.5现在已超过200K的未压缩大小，因为某些库的大小太大，无法证明这样做的好处。
2. 性能：编写本机JS总是比在库中抽象它要快。
3. 增加了复杂性：很多人实际上只需要其中的一些精巧功能时，就会下载整个jQuery库。
4. 应用程序依赖项：引入依赖项总是会遇到麻烦。如果jQuery中存在错误，则可以调试和编辑文件，但是稍后升级会带来问题。您可能会留下该错误，但是现在您要依靠jQuery的时间表进行修复，而不是您自己的。

因为通常这是不必要的。如果我想做的只是验证某些输入，或在某些字段上加亮，则编写简单的javascript / dom代码同样容易。jQuery在这种简单情况下并没有真正的帮助，所以问题应该是为什么要使用它？

显然，在许多情况下，它非常有用，但有时人们似乎也没有任何真正的理由使用它。

我宁愿使用jquery进行dom操作或遍历dom，这对于jquery来说确实很容易。此外，使用jquery或其他框架附加事件或事件委托非常容易，否则您必须为IE或非IE浏览器等编写自定义事件附件。

但是，当您使用$ .each而不是香草JS for和array.push（）时，它会带来一些性能损失...其他问题，例如，如果您绑定一个事件并在未取消绑定的情况下将其删除，则会导致内存泄漏。

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

为什么不使用jQuery？

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

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

就个人而言，我喜欢jQuery，但我知道使用其他框架的人效率也不低。