和往常一样，这次聚会我要迟到了。

并不是额外的功能让我决定使用jQuery，尽管它很有吸引力。毕竟，没有什么能阻止您编写自己的函数。

事实上，在修改DOM以避免内存泄漏时，有很多技巧需要学习(我说的是你的IE)。有一个中心资源来为我处理所有这些问题，由比我优秀得多的JS程序员编写，不断地审查，修改和测试，这是上帝的恩赐。

我想这应该属于跨浏览器支持/抽象的观点。

当然，jQuery并不排除在需要时直接使用JS。我总觉得这两者似乎天衣无缝地配合在一起。

当然，如果您的浏览器不支持jQuery，或者您支持低端环境(旧手机?)，那么一个大的.js文件可能是一个问题。还记得jQuery曾经很小的时候吗?

但通常情况下，性能差异并不是一个值得关注的问题。只要够快就行。由于每秒钟都要浪费千兆赫的CPU周期，我更关心编码员的性能，这是唯一不会每18个月功率翻一番的开发资源。

也就是说，我目前正在寻找可访问性问题，显然. innerhtml是一个有点不不。jQuery当然依赖于. innerhtml，所以现在我正在寻找一个框架，它将依赖于允许的一些乏味的方法。我可以想象这样的框架会比jQuery运行得慢，但只要它的性能足够好，我就会很高兴。

正确的答案是，当使用jQuery而不是“普通的”原生JavaScript时，您总是会受到性能损失。这是因为jQuery是一个JavaScript库。它不是什么花哨的JavaScript新版本。

jQuery强大的原因在于，它使一些在跨浏览器情况下过于繁琐的事情变得简单(AJAX就是最好的例子之一)，并平滑了无数可用浏览器之间的不一致性，并提供了一致的API。它还很容易促进链接、隐含迭代等概念，以简化一起处理元素组的工作。

学习jQuery不能代替学习JavaScript。你应该对后者有一个坚实的基础，这样你才能充分体会到了解前者会让你更容易。

-编辑以包含评论-

As the comments are quick to point out (and I agree with 100%) the statements above refer to benchmarking code. A 'native' JavaScript solution (assuming it is well written) will outperform a jQuery solution that accomplishes the same thing in nearly every case (I'd love to see an example otherwise). jQuery does speed up development time, which is a significant benefit which I do not mean to downplay. It facilitates easy to read, easy to follow code, which is more than some developers are capable of creating on their own.

在我看来，答案取决于你想要达到的目标。如果正如我根据您对性能好处的参考所推测的那样，您希望获得应用程序的最佳运行速度，那么每次调用$()时使用jQuery都会带来开销。如果你追求可读性、一致性、跨浏览器兼容性等等，那么肯定有理由支持jQuery而不是“原生”JavaScript。

这是我个人的观点，但无论如何jQuery是JavaScript，我认为理论上它不能比普通JS表现得更好。

但实际上，它可能比手工编写的JS执行得更好，因为手工编写的代码可能不如jQuery有效。

总之，对于较小的东西，我倾向于使用普通的JS，对于JS密集的项目，我喜欢使用jQuery，而不是重新发明轮子——它也更有效率。

和往常一样，这次聚会我要迟到了。

并不是额外的功能让我决定使用jQuery，尽管它很有吸引力。毕竟，没有什么能阻止您编写自己的函数。

事实上，在修改DOM以避免内存泄漏时，有很多技巧需要学习(我说的是你的IE)。有一个中心资源来为我处理所有这些问题，由比我优秀得多的JS程序员编写，不断地审查，修改和测试，这是上帝的恩赐。

我想这应该属于跨浏览器支持/抽象的观点。

当然，jQuery并不排除在需要时直接使用JS。我总觉得这两者似乎天衣无缝地配合在一起。

当然，如果您的浏览器不支持jQuery，或者您支持低端环境(旧手机?)，那么一个大的.js文件可能是一个问题。还记得jQuery曾经很小的时候吗?

但通常情况下，性能差异并不是一个值得关注的问题。只要够快就行。由于每秒钟都要浪费千兆赫的CPU周期，我更关心编码员的性能，这是唯一不会每18个月功率翻一番的开发资源。

也就是说，我目前正在寻找可访问性问题，显然. innerhtml是一个有点不不。jQuery当然依赖于. innerhtml，所以现在我正在寻找一个框架，它将依赖于允许的一些乏味的方法。我可以想象这样的框架会比jQuery运行得慢，但只要它的性能足够好，我就会很高兴。

已经有了一个公认的答案，但我相信这里直接输入的答案不能在本机javascript方法/属性列表中全面地保证跨浏览器支持。为此，请允许我把你引向quirkmode

http://www.quirksmode.org/compatibility.html

它可能是关于在任何地方的任何浏览器上什么可以工作，什么不能工作的最全面的列表。请特别注意DOM部分。要读的东西很多，但重点不是全部读完，而是作为参考。

当我开始认真编写web应用程序时，我打印出了所有的DOM表，并把它们挂在墙上，这样我就能一眼知道哪些是安全的，哪些需要hack。这些天，当我有疑问时，我只是谷歌一些类似quirksmode parentNode兼容性的东西。

和其他事情一样，判断主要是一种经验。我不建议你阅读整个网站，记住所有的问题来弄清楚什么时候使用jQuery，什么时候使用纯JS。只是要注意这个列表。搜索起来很容易。随着时间的推移，你会发现什么时候纯JS更可取。

PS: PPK(网站的作者)也有一本非常好的书，我推荐你去读

这里有一个非技术的答案——许多工作可能不允许某些库，比如jQuery。

事实上，谷歌不允许在他们的任何代码中使用jQuery (React也不允许，因为它属于Facebook)，直到面试官说“对不起，你不能使用jQuery，它不在XYZ公司的批准名单上”，你才可能知道这一点。Vanilla JavaScript绝对可以在任何地方、任何时候工作，并且永远不会给你这个问题。如果你依赖于一个库，是的，你得到了速度和轻松，但你失去了通用性。

另外，说到面试，另一个缺点是，如果你在代码测试中说你需要使用一个库来解决一个JavaScript问题，它给人的印象是你实际上并没有理解这个问题，这看起来有点糟糕。然而，如果你用原始的JavaScript来解决它，这表明你实际上理解并可以解决任何摆在你面前的问题。