在 最近的一期 ShopTalk 节目 中提出了一个关于在教程中使用 jQuery 的问题。
最近我开始意识到，在学习 JavaScript 语言时，jQuery 和 JavaScript 之间的界限变得多么模糊。很难找到一个不包含 jQuery 而是使用 JavaScript 的可靠教程。您对过度使用该库有什么看法？
这个问题来自 Nick Hehr，他 也写到了这个问题。您可以通过此 时间跳转链接 听到我们的回答。
如果您已经阅读过这个网站很久了，您就会知道我们在这方面有点“内疚”。我不确定这里是否曾经发布过仅使用“原生”JavaScript（即仅使用 JavaScript，不使用任何框架）而不是 jQuery 的教程。或者，即使有，也是凤毛麟角。这是一件坏事吗？我不确定。但这确实值得讨论。
稍后我发布了一篇文章，介绍了如何在事件发生后 替换文本。我介绍了五种方法。其中两种使用了 jQuery，另一种使用了原生 JavaScript，另外两种使用了 CSS。即使在其他选项中也包含 jQuery，也引发了一些“这有点过头了”的讨论
啊，很有帮助，但这里真的不需要 jQuery：替换文本，五种不同的方法 – https://#/5gyFGmoCVp
— Smashing Magazine (@smashingmag) 2013年7月3日
所以，我对这件事的看法如下。
我写我做的
此博客反映了我学习的东西。我经常使用 jQuery。因此，当我将内容翻译成教程时，我就会按照自己的方式去做。
在过去的几年里，我仅在少数几个不使用 jQuery 的网站上工作过，而那些不使用 jQuery 的网站则使用了其他一些库，或者根本不需要 JavaScript。
jQuery 就是 JavaScript
确实如此。使用 jQuery 实际上仍然是在直接编写和使用 JavaScript。jQuery 只是使它更容易，并降低了入门门槛。我知道很多优秀的 JavaScript 开发人员是从 jQuery 开始的。就像有很多优秀的吉他手是从 Dave Matthews 乐队翻唱乐队翻唱乐队开始的一样。
教程是概念
教程的目的是教授一个想法，并以简洁的方式做到这一点。
假设您想选择一个具有特定类名的按钮，并在单击时更改某些文本。为了避免任何依赖关系，也许您可以使用 document.querySelectorAll(".my-button")。但这将返回一个数组，因此您需要在末尾使用 [0] 来定位元素并附加事件。或者我们应该只使用 querySelector，它选择第一个元素？或者我们应该运行一个循环或映射数组以绑定到所有元素？或者我们应该使用 getElementByClassName？浏览器支持情况如何？我们是否应该讨论为此使用 polyfill？或者我们应该只添加一个 ID 并使用 getElementById，因为这可能是一种最佳实践？
或者，我们只需使用 $(".my-button") 并继续进行教程即可。所有这些内容都很有趣，值得讨论，但并非每个教程都需要每次都讨论。jQuery 允许教程中的概念脱颖而出，而不会陷入细节之中。
未来
目前，我感觉 jQuery 仍然是前端技术栈中非常重要的一部分，非常值得学习，并且仍然适合在教程中使用。
但网络上的情况将会发生变化。随着时间的推移，JavaScript 在教程中的呈现方式也会发生变化。可能吧。我们也会随之改变。可能吧。在过去的几个月里，我看到了一些评论，例如“我觉得如果我使用了 jQuery，说明我做错了”，我以前从未听过这种说法，这可能是变化的预兆。Ember/Angular 等新兴方法也正在兴起。
说得对！就这样做吧，我说。你完全正确。
Chris，你的每一篇文章对我都很重要。继续努力。上帝保佑你。
jQuery 是一个维护良好且文档齐全的库。在我看来，为了“JavaScript 纯粹性”而草率地放弃它是不明智的。事实是，如果您不使用 jQuery，那么您很有可能正在自己的库中重写 jQuery。
至于 JavaScript 作为 MVC 框架的未来，它们并非在所有方面都是 jQuery 的替代品。作为开发人员，我们需要谨慎地应对“新宠”。
我完全不同意。请查看我下面的评论（写完后）。
在我看来，jQuery API 已确立了操作 DOM 的最有效方法。我喜欢 JavaScript，但如果没有 jQuery 或类似的 API（如 Zepto），它就不会是现在的样子。浏览器终于提供了更多类似的方法，例如 querySelectorAll，但我们如何处理这些查询到的元素呢？我们知道 jQuery 中的事件绑定和元素操作的代码效率高且与浏览器兼容，因此此时进行回归测试将是浪费时间。除非有人能向我展示一个易于学习且语法更简洁的 API，否则我对此不感兴趣:)……如果它没有坏掉……
对我来说，jquery 是一种快速行动并测试概念是否有效的好方法。之后可以对其进行调查以改进、完善和重构，但为了提交代码，jquery 仍然是一个有效的选项。
如果您只知道 jQuery，那么当（不是如果）您最终在一个不使用它的项目上工作时，上帝保佑您的灵魂，并且您最好祈祷您在（不是如果）发生这种情况时不要在我的开发团队中。
嗨，Scott - 恭敬地讲，考虑到前端 Web 开发的糟糕状态（无论是否使用 jquery），您在这里（以及下面）的语气有点强硬。
我查看了您的简历，它显示 minivegas 网站同时使用了 jquery 和 wordpress。另一个说“您需要 iPad 才能体验此网站”（但也使用了 jquery）。第三个使用了 jquery 和 modernizr（另一个对 js 的抽象）。
因此，您需要解释一下，我恭敬地建议您不要对您自己似乎并不真正认同的观点发表如此强硬的意见:-)
我的评论是出于尊重，请您以建设性的态度看待它。
谢谢！
@ Scott Kosman
酷故事，兄弟……
作为一个新手（我认为有时我永远都是新手），很难找到原生 js 教程。一方面，如果一个 jquery 教程向我展示了如何完成某件事，那很好，我会接受它，但另一方面，我一直努力避免成为那些知道 jquery 但并不真正了解 js 的开发人员之一。我必须付出额外的努力才能找到不使用 jquery 的文章。Stack Overflow 上的问题似乎总是会有 jquery 答案，有时即使 OP 的问题明确要求使用纯 js 也是如此。所以我的意思是，我认为您在教程中使用 jquery 很好，但我认为整个行业都需要更多优质、详细、高级的原生 js 学习资源。
Stack Overflow 上的“OMG JUST USE JQUERY”人群让我抓狂。有时我会进行一波反对投票，只要有人做了你描述的事情：在没有被要求的情况下给出基于 jQuery 的答案。
关于这一点：“我认为整个行业需要更多优质、详细、高级的原生 JavaScript 学习资源”，我只能说，是的，是的，我的天啊，你一开口我就被征服了，是的。像 Stack Overflow（尽管我上一段话提到了它）和 MDN 等都是很棒的资源，但行业真正需要的（依我拙见）是一个好的“如何不用 jQuery 完成常见的 jQuery 任务”的资源。2012 年初，nettuts 上有一篇很棒的入门文章，但我们肯定需要更多这样的内容。
也许我应该开始写博客。
@Scott Kosman 我完全同意（你上面的评论和这里的回复）。向下滚动阅读我关于这个问题的简短吐槽，但确实是真实且诚恳的。
这里有一位新手。我的计划是在学习 jQuery 的同时，尽可能彻底地学习原生 JS。我将对原生 JS 拥有实用且有效的了解，但我可能大部分时间都会使用 jQuery。它真的太方便了。
关于你寻找 JS 文章的担忧：我不知道你怎么样，但我喜欢看书。有很多原生 JS 教程书籍可以学到非常高级的内容。如果你找对地方，我不认为找到 JS 资源有什么问题。
回应 Scott 的话，当 Stack Overflow 上没有要求使用 jQuery 时，人们却总是依赖 jQuery，这确实让人抓狂。我通常不介意，但很多时候我是在查找不经常使用的概念的原生方法，却得到了使用 jQuery 扩展的建议。我喜欢 jQuery，当简洁性有价值时，它绝对应该在教程中使用，但让项目依赖于 jQuery 的扩展却让我感到困扰。除了 jQueryUI 之外，我并不真正喜欢扩展。（事实上，很多时候我发现 jQueryUI 也很繁琐，所以我编写了自己的 UI 函数。）使用大量的扩展感觉就像用来自世界不同地区、使用不同语言的文档的不同组件来建造一辆汽车……而且这些组件可能在短短两年内就会过时。这太混乱了。
Ian，如果你正在寻找一套很棒的教程，可以看看 Nicholas Zakas 编写的《JavaScript for Professional Web Developers》。它是一部 10 分的作品，是你从新手到中等水平进阶所需要的一切。
http://www.wrox.com/WileyCDA/WroxTitle/Professional-JavaScript-for-Web-Developers-3rd-Edition.productCd-1118222199.html
我对此负有责任，主要是因为我发现 jQuery 很容易，而且在原生 JavaScript 中做任何事情似乎都需要花费我很多时间。
也就是说，仅仅为了实现可以用 JavaScript 轻松完成的事情而引入整个库，这似乎很疯狂。
我认为现在的问题在于人们何时开始学习 JavaScript。如果有人决定开始学习 js，他们会购买书籍，例如“Javascript the definite guide”，其中包含一些 jQuery 章节。他们会在 Stack Overflow 上提问，即使是像“如何切换一个 css 类”这样简单的问题，人们也会用 jQuery 来回答。
我个人认为，首先你应该学习 JavaScript，理解作用域继承、最佳实践等，然后“升级”到 jQuery，因为它可以加快速度，但思维模式已经形成了。我多次看到人们这样做
$(‘#divId’).each(…)
如果你稍微了解一些 JavaScript（或 HTML），你就会知道在一个页面中不可能有多个具有相同 id 的 div。
似乎 jQuery 正在逐渐成为一种完全平行的语言，而不是与 JavaScript 相比的“附加”语言，它更容易使用，并且可以在任何浏览器上运行。我不会感到惊讶，在不久的将来，浏览器制造商会在他们的引擎中优化 jQuery 例程。
好吧，jQuery 是我最初学习的“JavaScript”，但后来当我深入学习时，我也开始关注纯 JS。使用 jQuery 只是更容易地完成它，而且没有任何麻烦。
你提出的观点很好，但是仍然有很多空间可以开展“对 jQuery 说不的运动！”在我继续之前，让我先说明一点：jQuery 非常棒。当需要时我会使用它，对于那些理解 JavaScript 并需要额外帮助的人来说，它很棒。
这确实引出了你的第二点：jQuery 就是 JavaScript。没错。那么，为什么不懂如何使用 JavaScript 的人应该使用 jQuery 呢？我并不是说你（Chris）不懂如何使用 JavaScript，我的意思是，在你博客的无数读者中，有一些人不懂。当新手开始搜索像你写的文章（上面链接到的文章）或像这个视频一样的东西时，就会出现一个重大问题，其中包含 jQuery 仅仅是为了将文本（什么！？）附加到页面上。最终，读者会开始简单地包含 jQuery，因为他们错误地、颠倒地认为“JavaScript 就是 jQuery”。
现在，“JavaScript 就是 jQuery”（而不是“jQuery 就是 JavaScript”）的想法不会造成太大的危害（除了对 jQuery 用户不会学习的重要原则的公然无知之外），直到人们开始真正编写自己的 jQuery，而不是简单地复制粘贴。人们可以想象一下这场灾难的结果：丑陋、糟糕、绝对令人作呕的代码。这会导致那些认为自己懂 JavaScript（因为
JavaScript 就是 jQuery) 的用户进入社区，传播不良习惯，并寻求关于“更好的编码实践”、“代码优化”以及“OMG 为什么这不起作用！？”的帮助。……关于“重新发明轮子”和“编写全新的 JavaScript
框架库（说对了！）”的争论即将爆发。老实说，即使遇到最简单的事情，比如追加文本或删除元素，也会出现这样的攻击。对我来说，当我需要动画时，有时我会使用 CSS3，有时我会编写 5 行代码（真的！它不需要超过 5 行），嘿，有时我会包含 jQuery。在生产环境中，只要你知道自己在做什么，就可以继续做。当只涉及 HTTP 请求时，包含 jQuery 甚至没有那么有害，因为它经常被缓存。最大的问题是那些不知道如何使用 JavaScript 并且怀有“JavaScript就是jQuery”这种意愿态度的人。（这并不是说我不喜欢你的博客，并且每天都查看是否有新的文章、链接或视频……仅供参考）
“寻求关于‘更好的编码实践’、‘代码优化’的帮助”有什么问题？
看，人们在学习任何东西时都有不同的学习风格……我会在下面给出我个人的例子。根据我从你的评论中收集到的信息，我做错了什么。请记住，学习是通过知识与实践/经验相结合，并且通过实践/经验会有成功和失败。学习网络之类的东西的美妙之处在于它是完全开放的。
当 MySpace 还是流行且酷的时候，有一天我看到其他人发布了一个链接，该链接没有所有那些时髦的“https://www…”垃圾，但链接是他们帖子中页面的实际标题。我想“我也可以这样做吗？”。进行了一次谷歌搜索，并找到了一段
<a href="http://yoururlhere">Your Link Title Here</a>的代码片段。我完全不知道“a href”是什么。我复制/粘贴了它（倒吸一口凉气！），它运行得很好（更大的倒吸一口凉气！）。然后第二天，我想发布另一个链接。第二天，再第二天，再第二天……最后我对自己说“那个‘a href’到底是什么？”再次用谷歌搜索并找到了答案。下周，我尝试手动编写它而不是复制粘贴。它失败了。所以我又回去了，复制粘贴，比较，并弄明白了。
这激励了我。那个看起来像涂鸦版的 Geocities 的愚蠢的失败社交网站和我复制粘贴的学习激励我去学习更多关于网络编码的知识。今天，我有一份全职工作，负责网络编码，我还在学习，就像其他人一样。
请不要规定学习风格或方法。并且，为了开放网络的未来，请不要阻止学生寻求帮助。
也许我表达得不够清楚。帮助很棒。问题更好。好奇心很棒。不好的地方在于，当资源就在眼前时，人们却仍然请求帮助和提出问题。除非你色盲，否则你不应该问哪个球是红色的，哪个是白色的。jQuery 促进了这种行为。
另外，请原谅我的重复发帖，但在 jQuery 类别中关于更好的编码/优化的疑问通常源于从互联网上复制粘贴的代码，这些代码做了过于复杂的事情，而提出这些问题的人甚至不知道自己在问什么（更不用说他们投入到研究中的时间了）。
学习热力学的资源是可用的……所以我应该永远不要在资源可用时提出问题？为什么问题/答案不能成为资源？你再次规定了学习方法。不是每个人都通过阅读 W3C 或 ECMAScript 规范或 api.jquery.com 来学习。有些人通过辅导学习，有些人通过阅读学习，有些人通过倾听学习，有些人通过观察学习，有些人甚至通过先复制来学习。
要么我仍然表达得不够清楚，要么你故意曲解我的意思。以计算器为例：使用 wolframalpha.com 等网站是可以的。使用 TI Inspire 计算器是可以的。使用计算器是可以的。但是什么时候会过度使用呢？当你使用计算器做你不知道如何做的事情，并质疑为什么事情没有按照你想要的方式运行时。这听起来有点牵强，但请继续阅读。
假设我想在计算器上使用基本的乘法函数。我最终输入了一些类似
10/0的内容，因为我想要无穷大，结果却发现 10 除以 0 会导致错误……什么！？我想如果我们都不懂除法，直接把这些算式输入计算器，都会一脸懵。不过我第一次接触除法时，老师就在我身边，教我如何进行除法运算。**在质疑除法为什么这样运作之前，你需要先学会如何进行除法。**老师们都很棒，甚至可以说是伟大的。这就是我们需要向他们学习的原因。如果我们只使用计算器，我们就不会知道如何进行除法，不会了解其中的错误，也无法为后代创造计算器和教学计划。
那说话呢？我们并不会在学会说话之前就先学习正确的英语（或者任何你的母语）。但我们最终都成为了健谈的人，仅仅因为我们在模仿周围的人说话，而从未真正理解我们所说的话。是的，我们学习语法，但那是在多年说话之后。
你的方法可能适合你，但对其他人来说，它可能具有排斥性。它可能成为一种借口，让人们因为“学习不够”而永远无法构建任何东西。就我个人而言，我赞成任何能够降低入门门槛，让任何对编码好奇的人都能参与进来的方法。它能促进创造力和对这一蓬勃发展领域的兴趣。而且，确实会有人犯错误，幸运的是，我们拥有一个丰富的开发者社区，可以帮助引导人们走向正确的方向。
你的观点很有意思。在我说任何其他话之前，我想先声明一点，我并不是试图禁止或阻止人们以他们想要的方式学习。
至于说话，你是对的。我们学习说话是从片段、单词、含糊不清的声音和哭声开始的，但那是自然的顺序。就像我们学习 JavaScript 一样。我们不会通过使用诗歌、短信缩写或写作小说来学习说话……最终，我们通过我们的说话方式创造了自己的语言（例如，我们每个人说话的方式都不同，就像我们每个人都有不同的编程方式一样）。
现在来谈谈学习的视角。过去，我在论坛、问答网站和聊天室里帮助过数千人学习编程。根据我的经验，人们只有在真正“理解”的时候才会明白。有一些“吸血鬼式求助者”，他们会一遍又一遍地问同样的问题（你最好相信，这个问题已经被回答过很多次了），并且使用了像 jQuery 这样的框架。但也有那些真正想要学习的人。他们会从一个相当令人恼火的“吸血鬼式求助者”的问题开始，然后他们会接受建议。我亲眼见过他们的头像（在聊天室里你看不到眼睛）在他们理解 jQuery 函数为什么这样运作时亮了起来，而他们只有在简单地了解了原生 JavaScript 之后才会明白。
我希望这说得通。
我认为 jQuery 更像是俚语，而不是诗歌。有很多东西没有被表达出来。我们学习俚语是在学习“正确的”英语之前。它使用和交流起来更有效率，只要语境正确，它就是首选的表达方式。它可能不会让你显得聪明，但它能完成工作。
我不得不不同意“jQuery 更像是俚语”的说法。但是，让我们采用这种方法来证明为什么 jQuery 不应该用于简单的事情。假设史密斯先生正在教课上关于动词和名词的内容。我怀疑他会选择像“我今天看到的那篇特色文章笑死了，我的天哪。”这样的句子。他会选择一个语法正确的句子，以便学生首先理解什么是动词。之后，他可能会插入“笑死了”作为动词（或动词短语）来展示元素如何可以被交换。
所以，根据你的类比：jQuery = 笑死了。
在我看来，一篇成功的博文，尤其是在我们讨论代码时，应该以一种尽可能多的读者都能理解的方式提供教程。原生 JavaScript 当然有其地位……但是当 jQuery 正在迅速成为首选库时……为什么你不展示 jQuery 中的代码是什么样子的呢？
在某些情况下它会过度使用吗？当然。但是如果我已经在我的项目中使用了 jQuery，我更倾向于尽可能继续使用 jQuery 语法，以便我的代码保持一致。我的网站会受到性能影响吗？这取决于我的代码，然后当然，这种影响是否重大到需要更改代码？
某些“jQuery 对此并不必要”的论点中存在一定程度的精英主义和讽刺意味。归根结底，没有任何项目是绝对“需要”jQuery 的。jQuery 旨在简化你的流程，并为你提供一个良好的工作基础（因为谁想重新发明轮子呢），而不是神奇地为你提供一些你以前无法使用纯 JavaScript 实现的东西。
我同意，精英主义非常猖獗。
你的教程做得很好。我遵循 80/20 法则。80% 的项目只需要完成跨浏览器的工作，因此开发者可以使用 jQuery 或其他库来帮助他们完成工作。剩下的 20% 是真正需要原生 JavaScript 的项目。
正如你在另一篇文章中提到的，一旦全世界停止使用 IE9 及以下版本，你就可以更多地强调 W3C 和 HTML5 的原生方法、属性和对象，但在那之前，jQuery 及其同类仍然在开发世界中占据一席之地。
我发现网络人群很有趣……一方面，那些酷炫的网络小子们说，使用 CSS 预处理器吧……它让编写 CSS 更容易……并且让你远离编写“纯 CSS”……然后，这同一群人又说……不要使用 jQuery，即使它让编写 JavaScript 更容易，而是要编写纯 JavaScript……真正的开发者永远不会使用 jQuery……
我使用 jQuery 是因为它让编写 JavaScript 更容易……它消除了很多跨浏览器问题，这样我就可以专注于代码的逻辑……我可以像使用几个字符的代码来按类名选择元素并切换类一样做事情……也许它比纯 JavaScript 慢了毫秒级的时间，但对于网站工作……也就是我所做的，它足够好了……
Chris……请继续在你的教程中使用 jQuery……就我个人而言，我喜欢 jQuery 代码的外观，而不是纯 JavaScript 代码的冗长外观……
我完全同意你的观点，我在几乎所有项目中都使用 jQuery，但 CSS 预处理器是不同的。它们在推送到服务器之前会编译成纯 CSS。这意味着根本不会有任何性能损失。
如果 jQuery 编译成纯 JS，然后我们将它推送到服务器，那么这将是一个公平的比较。**实际上，如果任何人在寻找一个很棒的新工具来构建，这个免费的想法送给你了。**；)
@Josh – 我认为关于最终结果差异的观点非常棒，尽管它确实有点忽略了 Michael 的观点，即预处理器不一定从一开始就是纯 CSS，因此那些从预处理器开始编写 CSS 的人可能会遇到与 jQuery -> JavaScript 类似的逻辑问题。对我来说，最明显的问题是假设纯 CSS 允许嵌套项（&:before 等）。
不过我有一个问题……也许它真的只是“取决于……”jQuery 相对于纯 JavaScript 到底会带来多大的性能损失？我们是在谈论毫秒级的处理时间吗？它是否重大到足以说“是的，这里真的应该使用 JavaScript”或者更多的是“我更喜欢……”
我会利用节省下来的时间重用代码去做其他事情，比如玩得开心。干杯！
在一个客户对独角兽网页设计师的需求日益增长的世界里，我欣赏那些在前端设计方面保持 T 形专长的人。如果我想了解更多关于用 Javascript 和 Jquery 编写代码的细微差别，我会去 jquery-tricks.com 或 javascript-tricks.com；但我不会这样做。我目前只想成为一名非常优秀的 CSS3 和 HTML5 开发者。所以，Chris，继续做你正在做的事情。
@Jeremy：你应该在上周就这个话题发表我的演讲（演讲幻灯片）。
这绝对是现在的一个热门话题。不可否认，jQuery 非常棒，并且在过去 6、7……9 年（无论多少年）里让前端开发人员的生活变得更加轻松。但是，当时至关重要的浏览器兼容性问题现在已经不再那么麻烦了。
因为 jQuery 比 JavaScript 更容易而学习它是一种错误的方法。这并不意味着使用 jQuery 是错误的，但如果不理解你使用的工具，会导致许多意想不到的问题。
这总结了我的想法
对于教程，我宁愿看到没有 jQuery（或任何其他库）的选项——除非你想要实现的目标如果没有它们根本无法实现。
幻灯片不错。
DOM API 没有任何“原生”可言，它就像任何其他库一样，只不过它恰好默认包含在最常见的 JavaScript 运行时环境中，即 Web 浏览器中的那些运行时环境。将 DOM API 与 JavaScript 语言混淆与将 JavaScript 与 jQuery 的 API 混淆一样不正确。只是前一种混淆比较古老，因此感觉更自然。
客户端开发的一些特殊性似乎导致一些 JS 开发人员对库和框架抱有一种在服务器端编程或其他更传统的开发类型中不常出现的怀疑态度。事实是，你所有的代码，即使你正在编写直接在 CPU 上执行的汇编语言指令，仍然是对某些更深层复杂性的抽象，并且在现代应用程序编程中，你始终在使用包装了 API 的 API 的 API。无论这些 API 是由运行时提供还是由第三方组件提供，都不重要。重要的是：它们是否有效？它们是否帮助你解决了问题？它们是否有良好的文档和支持？
大多数服务器端开发人员会轻松地依赖十几个或更多库和框架，这些库和框架有助于 HTTP 处理、内容管理、数据序列化、持久化、编码等。PHP、C# 和 Java 开发人员是否应该在深入研究某个所选 Web 框架的抽象时将其抛弃，转而处理原始套接字，因为这 somehow 更加“原生”？不，那会是疯狂的。
如果你不需要 jQuery，那么就不要使用它。如果你可以通过不使用它来获得可衡量且重要的性能提升，那么就不要使用它。但不要为了毫无意义的编程纯洁性概念而牺牲自己，拒绝一个 API 而去使用一个更糟糕的 API。发布好的软件已经足够困难了。明智地利用每一个可以让你生活更轻松、让你的产品更好的框架、组件和库。
简单地说，编写原生 JS 本质上对性能更好，这是一个荒谬的说法。尝试编写一个既能胜过 SizzleJs（jQuery 的选择器引擎）又不会浪费大量时间的选择器引擎。
我完全同意你的观点——我并不想写成这样作为回应 :(
+1000
@Cp Man，完全使用 Sizzle 可能是一种浪费时间！
在 99% 的情况下，你可以不用 CSS3 就能选择元素（不要告诉我你真的需要那个扩展的
:not()语法……），对于剩下的……你可能甚至不需要选择那些！或者你可以使用简单的 JavaScript 迭代更快地完成它。好吧，无论如何，你可以依赖 Sizzle。但是你也可以单独使用 Sizzle，而不用 jQuery :) 我这样做是为了为 IE7（用于
querySelectorAll）和 IE8（用于matchesSelector）提供一个 polyfill。效果很好。用 jQuery 教别人 JavaScript 是错误的，但教程并不是语言的入门介绍。它们是为了教授新东西。如果你正在阅读教程，那么你已经了解了一些 JavaScript，并且既然你很有可能也了解一些 jQuery，在我看来，这似乎是可以的。
我认为可以公平地说，一些（不是全部）JS 开发人员感觉他们的“地盘”正受到某些人的入侵，特别是设计师，他们完全依赖 JQuery 将动态元素构建到他们的网站中。我看到很多 JS 纯粹主义者非常反对人们依赖 JQuery，但每次开始一个项目时都没有任何顾虑地引入 Bootstrap。虽然我不会争辩说 JS 在大多数情况下比 HTML 标记和 CSS ‘更深’、更复杂，但良好设计的理论与我遇到的任何 JS 一样复杂。
因此，虽然 JQuery 新手确实应该学习一些基本的 JS，但我认为对于那些依赖 Bootstrap 来‘美化’他们网站的开发人员来说，也是如此。花多少时间学习排版、响应式设计或色彩理论？Bootstrap 是预打包的 CSS，而 JQuery 是建立在原生 JS 之上的，它们之间是否存在一些根本差异？当然，但它们最终提供了相同的东西：一座通往你可能不熟悉甚至完全无法触及的学科的桥梁。
我从 90 年代后期就开始使用 JavaScript，但肯定不是专家（并且在某种程度上难以理解更现代的 OOP 方法）。几年前当我开始使用 jQuery 时，事情开始变得明朗起来，我的能力也以更快的速度提高了。
因此，虽然一些纯粹主义者可能会说 jQuery 仅适用于初学者，但我认为这取决于你的学习风格。如果更容易意味着更多设计师开始进行交互式开发，那有什么不好的呢？为什么要通过让事情变得更难来设置更多进入壁垒？
我同意那些新手，在开始时，如果你有正确的思维方式，在使用 jQuery 之前理解 JavaScript 非常重要。而且在你编写教程时，你的受众中总是会有新手。
但是，为了保持纯洁，是否值得将一个例子写成 10 行代码而不是 5 行？我会说不需要。你应该假设‘每个人’都知道 jQuery 是什么（现在）吗？我会说不需要。
我之前写过一篇帖子替换 jQuery。这是在我连续完成的第二个非 jQuery 项目之后（两个都是小型网站，没有 DOM 操作或 AJAX）。而且我对只在真正需要时才使用 jQuery 的概念获得了大约 50/50 的正面/负面评论。
我发现尝试通过谷歌搜索查找与 Javascript 解决方案相关的信息非常恼人！那里大多是 jQuery！
WTF
框架的选择应该取决于项目需求，而不是工具包宗教。
真正让我惊讶的是，在这个帖子中完全缺乏对 prototype.js 的了解。我相信它是 jQuery 的对应物。JQ 使用函数式方法，而 prototype.js 扩展了语言本身。JS 是一种基于原型的语言，因此在我们编程语言的动物园中相当独特。Prototype.js 不是唯一使用原型扩展的框架，但可能是最成熟的一个。
如果你真的对编程感兴趣，而不仅仅是在寻找 marquee 替换，那么你绝对应该学习这三种：JQ、prototype.js 和原生 JS。
作为一名开发人员，我需要我的代码能够在所有浏览器中运行。此外，我需要快速开发……jQuery 帮助我编写更快、更简洁的代码，这些代码在所有浏览器中（几乎）都以相同的方式执行。我认为这没什么问题。好吧，它的性能比原生 JS 慢，但在生活中，一切都是妥协 :)
我倾向于在编码时大量使用 jQuery，但这仅仅是因为在很多情况下，与原生 javascript 相比，我感觉更舒服。对我来说，现在让某些功能正常运行并发布出去比浏览 StackOverflow 的页面以查找满足我特定需求的合适答案更容易。
不要误会我的意思——如果我遇到我知道可以用原生 javascript 处理的情况，那么我不会包含 jQuery。这可以简化页面加载时间。
我认为，如果你了解 jQuery 并感觉很舒服地使用它，那么这样做没有任何问题。它并不逊色，并且功能相同或更好。
我见过一些网站和一些开发人员出于某种原因拒绝使用 jQuery 和其他库。这对我来说没问题，那是他们的网站和他们的代码，不是我的。
我过去不喜欢在教程中使用 jQuery。我不理解语法。所以这是一个风险。现在，我对 JavaScript 比较熟悉了，我不介意了。
尽管如此，我认为最好将 jQuery 限制在 DOM 选择和事件上，不要过度使用链式调用。
虽然我同意你应该写你了解的东西（毕竟这是你的博客！），但看到几乎每个关于 Javascript 的教程或 Stack Exchange 答案都只有 jQuery 解决方案，这让我很恼火，尤其是在你使用移动设备时，那里有很多框架，如果你还没有使用 jQuery，添加它会占用太多内存，这对移动设备来说负担过重——一个框架就足够了。
有时当你看到 jQuery 中的答案比纯 Javascript 中的答案更复杂时，这尤其荒谬。看到这些总是很有趣的。
完全同意，尤其是关于陷入细节的那部分。我在这篇帖子中也说了同样的话，这篇文章也是对别人的回应
http://www.impressivewebs.com/why-use-jquery-simple-tutorials/
虽然我在这篇文章中的一些陈述，事后看来，有点过于大胆，但我只会引用两段仍然反映我当前观点的段落
很棒的话题！作为一名招聘人员，我经常听到初级前端开发人员（例如，两到三年的经验）告诉我 jQuery 和 JS 完全一样。（叹息）。我对此的后续问题是，“那么，如果出于某种原因 jQuery 没有提供你正在寻找的解决方案，你能用纯 JS 开发一个解决方案吗？”我告诉他们问这个问题的原因是因为我为其招聘的公司要求在面试过程中进行纯 JS 测试。听到这一点，我得到的答案大约 95% 的时间是……”呃……嗯……好吧……呃……我可以试试”。通常高级开发人员（例如，10 多年）会说，“放马过来”。
.
我认为 JavaScript 应该有自己的教程，而无需 jQuery。我一开始只学习 jQuery，但后来意识到我应该先正确地学习原生 JavaScript，以便更好地理解这门语言，并有效地使用 jQuery 或其他 JavaScript 框架。如今 JavaScript 应用于各个平台，因此，似乎应该单独认真学习 JavaScript。我也在我的博客上发表了一篇关于这方面的文章
https://sarfraznawaz.wordpress.com/2012/02/12/learning-javascript/
完全同意在示例中使用 jQuery 是可以的，因为它简单、简洁且可靠。那些不熟悉原生 JS 的人不会被它的古怪特性所困扰，并且可以仅仅享受文章（通常是关于 CSS 的！）
更广泛地说，我不禁认为这里所有原生 JS 的布道者都过于乐观了。绝大多数企业级开发都无法忽略 IE8 及以下版本，因此您**需要** jQuery 来简化您的工作。如果您有任何稍微复杂一点的内容需要在旧浏览器中运行，请省去麻烦，用 jQuery 来编写，它易于学习，并且有很好的文档。
最近我很幸运地参与了一个只需要在 IE10 和 Chrome 中运行的应用程序的开发。作为一名坚定不移的 jQuery 爱好者，我用它完成了该应用程序的一部分功能，并在对解决方案感到满意后，尽可能地重构了 jQuery 代码。它非常直观，并不一定需要将每个教程都重写成无 jQuery 的版本。
这里有一点务实精神非常重要，而且您有足够的时间来学习两种风格的 JS。IE7/8/9 不会很快从贵公司的统计数据中消失！
我认为教程应该告知读者如何正确地做事并养成良好的习惯。用 jQuery 教他们可以帮助他们做到这一点。例如，在 JavaScript 中，您可以用一行代码写一些东西。但随后许多变量会发挥作用，比如跨浏览器兼容性，如果发生这种情况怎么办，关于 blah 的情况又如何呢？突然间，这变成了 10 行代码，甚至更多，如果您必须为其他几个浏览器进行复杂的跨浏览器处理。有人发现，嘿，我最终可以用一行代码实现这个功能，而且在没有完全理解的情况下可能会删掉大量代码。jQuery 通常包含了所有这些内容。幸运的是，大多数项目都会允许他们使用 jQuery，他们可以逃脱这种做法。我所知的理智的项目经理都不会反对它，而且通常客户不会设定语言技术规范，除了选择 Ruby、PHP、Python、ASP 并让开发人员自己选择。
但我必须说，并非所有项目都是这样。我参与过一些项目，它们只要求使用 JavaScript，而 jQuery 不是选项。但这些项目使用 JS 作为外部脚本语言，而不是网站或 Web 应用程序。
但话虽如此，如果您认真对待 Web 开发，请学习 JavaScript。当我们面试那些说他们了解“jQuery”但对 JavaScript 不太精通的开发人员时，95% 的情况下他们都不会收到回复。
当我开始学习 Javascript 时，已经存在几个 Javascript 框架了。我拒绝学习和使用它们，因为感觉好像有人在为我工作——这让我感到困扰。
现在听起来可能很傻，但我感觉需要深入学习这门语言。我必须了解 Javascript 的工作原理，并详细了解它。这让我对这门语言有了更深刻的理解。以及为什么 jQuery 在许多我认为什么微不足道的任务中如此缓慢。
jQuery 不允许这样做。jQuery 几乎就像一门新语言，在编码哲学和语法方面。在原生 Javascript 中您可以做一些事情，但是使用 jQuery 您应该采用完全不同的方法来保持一致性——在代码长度甚至清晰度方面没有任何特别的收益。
此外，jQuery 有自己的工作方式。如果使用不当，即使在更现代的浏览器中，它也可能导致巨大的内存泄漏或成为 CPU 占用大户（Twitter 深受其害）。这就是为什么它就像一门全新的语言。你见过多少次初学者做这样的事情？
等等，使用
$("#field")。甚至更可怕的是不要误解我的意思，jQuery 很棒。它是任何面向互联网广大公众的网站的首选武器。在过去，忘记 IE 的遗留方法以及浏览器之间的大量其他不兼容性和不一致性是一种解放，并且现在仍然如此。而且 jQuery确实节省了很多代码输入。但它也有其缺点。
首先，它速度慢且内存消耗大。因此它不适合所有情况。不适合依赖于高性能的应用程序，例如许多使用最新 Web 技术的应用程序。
因此，许多开发人员实际上希望了解原生 Javascript 的解决方案是可以理解的——因为他们可能根本没有使用 jQuery。
幸运的是，大多数开发人员实际上都了解一些 jQuery——足以理解正在发生的事情。大多数示例和教程都以一种简单的方式使用 jQuery，通常是为了省去他们创建 polyfill 来添加事件监听器的麻烦，而不仅仅依赖于
addEventListener并阅读一些新手抱怨为什么代码在 IE8 上无法运行。因此，实际上，如果您对 Javascript 的操作足够简单，您可以使用 jQuery：初学者可能会使用它，而更有经验的程序员则不会有任何问题理解它。但是**始终**详细描述您正在做什么，即在您代码的（几乎）每一行中。像
$("#container").find("input")这样的东西对于不习惯 jQuery 的人来说并不完全是简单的。（最好的方法是编写代码的两个版本——使用 jQuery 和不使用 jQuery。但这将非常耗时。）
如果您正在处理某些现代 Web 技术，**始终**使用原生 Javascript——并且可能添加一些类似“您可以使用 $(…) 来节省一些麻烦”的内容。
“我可以通过把头伸进公牛的屁股里来仔细观察一块 T 骨牛排，但我宁愿相信屠夫的话。”
作为一名 Web 设计师/前端开发人员
Markdown 完全不起作用，哈哈。
100% 同意
请随时告诉我它哪里坏了。从我看到的您发布的内容来看，它被正确地解释为 Markdown。
这取决于您所说的“更快”是什么意思。如果您指的是“开发速度更快”，您可能是对的。但是，如果您认为它是“执行速度更快”，那就错了。
这是一个明智的做法。
哦，是的，有：阅读一个使用[在此处插入一些 JS 框架]的教程。什么？你不习惯[前面提到的 JS 框架]？真可惜。（我希望你明白我的意思。）
确实如此，但是抱歉，我不明白您在这里的意思。您是在暗示有一个好的地方可以询问和学习 jQuery 吗？你知道，原生 Javascript 也是如此。
/ 6. 你不必因为你是网页设计师而感到内疚，所以你不需要深入了解 Javascript。这是可以理解的。但如果 Web 开发人员告诉你：“我们正在使用[前面提到的 JS 框架]，请也使用它”呢？
是的，Markdown 在我的消息中惨败了:(
在预览中它看起来很好，但当我发送它时，所有数字都消失了。
Chris，请帮忙:(
如果 jQuery 在社区中不那么流行，我们手头的资源是否会如此丰富且易于获得？
不错的掩饰..
我是一个新手，已经开始学习 JavaScript 了，但更喜欢使用 jQuery，因为它编码速度稍快。有趣的是，我今天也在思考是否最好使用 JavaScript，因为它才是祖宗。无论哪种方式，我都要同意双方的观点，即出于演示目的，我认为使用 jQuery 很好（每个人都知道它，并且对于那些了解原生 JavaScript 的人来说，很可能知道如何调整语法以便能够用 JS 编写它），并且 JavaScript 确实需要像 jQuery 一样多的关注，例如教程等。
两者都很重要，并且可以争论哪一个更好。如果它有效并且在上下文中是有意义的，为什么不使用它呢？绝对不是一件值得大发雷霆的事情。
保持冷静，互相支持，让我们为社区发展做出贡献！
我认为使用 jQuery 很好，尽管确保人们理解 jQuery 是一个库/框架，而不是语言规范的一部分可能会有益。我对此的看法与我对任何其他语言的看法相同。你学习 Java 的基础知识，但你也会学习 Apache Commons、Java FX、Spring 和其他使你的生活更轻松的库。
一位全面发展的程序员了解语言及其可用的库。
抱怨为什么使用 jQuery 就如同抱怨为什么使用 WordPress，因为还有其他 CMS 拥有更多功能、更多特性等等。
新闻快讯。它们很受欢迎。人们在寻找它们。这是一种供求关系。
真的吗？你把 Javascript – jQuery 的争论比作 CMS 之间的比较？这完全不是讨论的重点。
有些人可能已经注意到，jQuery *是* Javascript，因此从定义上讲，Javascript 比 jQuery 更受欢迎。如果你考虑受欢迎程度，那毫无疑问。
重点是是否使用 Javascript *框架*。它可以是 jQuery、Dojo、Prototype…… jQuery 被使用是因为它*是*最流行的框架。但我们不是在谈论选择框架。
我不明白为什么这对 Javascript 原教旨主义者来说是一个问题。如果你阅读了关于使用 jQuery 的某个内容的教程，并且你知道如何在原生 Javascript 中完成它，那么……使用 Javascript。为什么要攻击使用 jQuery 的人？有些人不喜欢原生 Javascript API，而 jQuery 将它们包装在一个更符合他们使用习惯的形式中，那么有什么问题呢？
jQuery 保持非常受欢迎是有原因的，那就是因为人们喜欢它。它帮助他们实现他们想要的目标，仅此而已。坦白地说，我宁愿看到一个可能对 Javascript 一无所知但可以用 jQuery 创建出色作品的人。当然，Javascript 原教旨主义者会说“我可以用原生 Javascript 完成它”，但同样，这无关紧要。使用 jQuery，那个人创造了一些杰出的东西。如果没有 jQuery，他可能做不到。
我认为 Javascript 流行度的提升也归功于 jQuery。如果没有 jQuery 的流行，我认为 Javascript 不会达到现在的状态。即使是最流行的 JS MVC（Backbone、Ember、在某种程度上 Angular）也使用 jQuery。
接下来是什么？不要在原生 CSS 上使用 SCSS/LESS 吗？
“错误”在于 jQuery 只是 Javascript 世界的一部分。许多开发者——不仅是初学者——可能对 jQuery 了解不多，甚至完全不了解。因此，如果你建议“那么使用 Javascript”，如果开发者实际上无法将 jQuery 转换为 Javascript，那么这个建议就毫无用处。
精通 jQuery 的作者可能倾向于使用复杂的语法结构并滥用链式调用，这对想要阅读教程的人来说将是一场噩梦。
并且让我们承认：对于大多数事情来说，jQuery 过于复杂了。我的意思是，不仅仅是教程中的内容——而是对于 Web 开发的整体而言。一个优秀的开发者可以编写一些辅助函数来附加事件监听器、添加类和进行 AJAX 调用，这将涵盖开发者使用 jQuery 所做的大部分操作，同时使用更少的内存和 CPU。这一点经常被遗忘，但随着 IE8 的逐渐淘汰，jQuery 变得越来越不重要（我确信 John Resig 不会介意——其他框架也是如此）。
因此，最终，我认为在非常基础的事情上使用 jQuery 是可以的，例如添加一个类或一个事件监听器，仅仅是为了展示如何应用一个效果。因为即使是
$.get或animate对初学者来说也可能相当晦涩。对于更复杂的事情，请使用原生 Javascript。当然，除非这是一个专门针对 jQuery 的教程。是的，下一步是质疑是否应该使用原生 CSS 而不是 SCSS/LESS，并且程度更大，因为 CSS 框架在 CSS 中的流行程度远不如 jQuery 在 Javascript 中的流行程度，因此它们对初学者来说更加晦涩——也就是最常见的教程读者。
附注：我不认为 jQuery 对提升 Javascript 的流行度有很大帮助。每个浏览器现在是否都实现了
querySelectorAll并不重要，这只是微不足道的。对于 Javascript 的兴起，你可以感谢标准兼容 Web 浏览器的兴起，特别是 Firefox 和 Chrome。我最近开始看到用各种不同的 Javascript 模式编写的教程，我开始学习这些模式，以便能够完全理解和转换 Javascript。
当我开始学习 Web 开发时，我开始学习和使用 jQuery，但不知何故，我感到空虚，并且觉得有必要学习纯 Javascript，现在我不断学习更多，并且只在某些不可预测的时间变短时使用 jQuery，好吧，让我说得更清楚一些……当时间变短时，我使用“jQuery 插件”，除此之外，我使用纯 Javascript，我爱它。
我发现 IT/开发世界，就像其他许多领域一样，非常两极分化，并在某种程度上荒谬地如此。Linux 与 Microsoft，jQuery 与 JavaScript 等等。接下来是什么？基于你选择的开发语言或平台的抗议和战争？是的，这很极端，但我看到了一些关于技术的非常激烈的辩论，并且只会摇头走开。再说一次，之前那个荒谬的占领 Flash 事件……真的吗？
我们从事这项工作是为了提供解决方案——无论是基本网站、电子商务、游戏等等。我不知道我们有一个客户曾经说过“我们不希望你使用 jQuery，只使用纯 JavaScript”。大多数人也不在乎。他们关心的是他们希望交付给他们的客户/顾客的体验是否满足（或超出）他们的期望。
对我来说，更重要的是要了解你选择的工具、语言、平台，并知道如何充分利用它们来实现你的目标。你应该了解它们的优势、劣势、注意事项以及何时何地不应该使用它们。
如果你的 jQuery 代码造成了性能问题，请对其进行优化。如果它是最佳的，那么转向纯 JavaScript。
我不想在一个开发团队中工作，在这个团队中，负责人仅仅因为他不/她不认为 jQuery 是“纯的”而将其丢弃。我们是否不应该使用 IDE，因为它们也使编码更容易？谁需要调试器、跟踪、分析、代码补全……是的，我宁愿用更多工作来完成同样的事情。
如果你有兴趣和倾向，请学习你所能学习的。绝对要学习 JavaScript，这对你来说会更好。但不要因为一个人不是 JavaScript 忍者而将其贴上无能的标签（顺便说一句，我厌倦了看到招聘描述中要求忍者、大师、代码战士等等。他们期望你穿着你的旋风忍者服装出现吗？）。
我完全同意并赞同 MG 刚才所说的话，正如 Chris 在他的文章中巧妙地说到的
浪费时间争论 jQuery 的使用或误用毫无意义。那些明智地使用它的人已经部署了许多成功的项目（我可以说，我其中之一）。编写大量纯 Javascript 代码而取得的成果很少，而使用 jQuery 可以轻松做到这一点，这是毫无意义的。
简而言之，使用 jQuery、Zepto、underscore 或纯 js，无论哪一个能为你提供最佳性能并为你的编码风格提供最大的灵活性。就此打住。
我认为 jQuery 不适合简单的教程，其中教程与 jQuery 无关。如果你想摆脱 <IE9 事件模型和其他兼容性问题，教程应该只提及一个垫片来在 IE 中获得相同的行为。就像
$(element).removeClass("active");可以通过原生 javascript 使用element.classList.remove("active");来实现一样。只需指向添加支持的垫片即可。重要的是给定任务是否以令人满意的方式完成。其他一切都是闲话。
没错：当有时对你客户来说最好的事情可能与你的偏好相反时，以这种或那种方式坚持己见是不明智的。然而，许多前端甚至一些后端 Web 程序员并没有采取这种工程方法。他们要么重视外观和感觉胜过实用性，要么仅仅盲目地选择对他们来说工作量最少的解决方案。
话虽如此，但我经常在手机上访问网站时会想，“为什么 jQuery 的华丽效果在我的缓慢、计量连接的小屏幕上加载？我甚至还看不到我来的目的！”
我成为 Web 开发人员还不到 3 年，直到过去一年我才学会使用 jQuery/JavaScript，我不太明白为什么人们对学习 jQuery 而不是 JavaScript 如此激动。
如果使用 jQuery 能使工作更容易，那么就使用它。我可能不是说这句话的合适人选，但使用 jQuery 确实要容易得多，因为你编写的代码从字面上来说就是你用速记的方式表达它。
你完全正确，Charlie，jQuery 比原生 JS 易用得多。当你有一个网站需要大量脚本时，它通常是完美的解决方案。此外，jQuery 的生态系统很棒（有如此多的插件可供选择！）。
但这种易用性正是 jQuery 会被过度使用的原因。有时，当只需要复制粘贴修改 10 行原生 JS 代码时，jQuery 被添加为一种过度解决方案，从而不必要地降低了网站的下载速度，降低了页面排名等等。当一把普通的螺丝刀可以更快更便宜地工作时，没有必要购买电钻。
+1
我很容易理解这个概念，即你应该先学习语言，然后再将自己包裹在一个预先编写的框架中，然后简单地应用 API。当然。
就像Jake指出的那样，我也看到一个非常庞大的开发者社区在使用Bootstrap及其所有将Bootstrap视为平台的工具。更不用说那些抓住机会安装Angular-Bootstrap的新一代Angular开发者了。
当一个开发者，而不是学习如何更好地构建良好的CSS并使用正确的架构实践，而是默认选择直接从货架上获取Bootstrap时，难道这不是同样的问题吗？
几乎每个在这个帖子中说“你不需要jQuery来做X”的例子，我都可以用Bootstrap提出同样的论点。
如果我因为在项目中添加了93k的jQuery来简化我的工作而被批评，那么我是否有权说添加Bootstrap（98k最小化版本）同样糟糕呢？
我认为，我们作为一个社区，需要减少花费在批评那些没有做“被认为是”正确的事情的人的时间，并理解我们每个人都有自己的工作要做。随着时间的推移和经验的积累，我们会开始重新评估我们的工具集，并开始自己构建。
</和平>
^^赞同。