很多人提倡“只使用纯JavaScript，根本不需要jQuery”。好吧，很多东西确实是我不需要的，尽管它们可能都很好。我可能也不需要jQuery，但它确实也很好。

有些文章试图告诉我们：去掉jQuery其实是很容易的。但这篇文章在开头却举了一个使用jQuery很好的理由：一行简单的jQuery代码取代10行vanilla JS（纯原生JavaScript）代码！

使用jQuery的优势

JavaScript API（特别是DOM API）的很多东西都与我的审美观相去甚远，我这么说算客气的。el.insertAdjacentElement(‘afterend’, other)固然没有问题，但如果写成$(el).after(other)不是更好吗？虽然我也不是那么喜欢$()函数，但它再怎样都比DOM提供的函数要好得多。

通常你是怎么获取一个元素的兄弟元素的？是nextSibling还是nextElementSibling？它们有什么不一样吗？哪些浏览器支持它们？又或者不支持？为了记住这些，你需要记住或者去查阅MDN，但如果使用了jQuery，只需要调用next()或者prev()方法。

JavaScript API提供的很多标准操作都很奇怪，我本来可以列出很多，不过上面提到的那篇文章已经列出了一大部分了。

你可能还需要一些辅助函数来完成一些常见的任务，同样，上述的文章也列出了很多这样的函数。而jQuery就包含了这些东西，省得你到处拷贝粘贴这类代码。

虽然现在浏览器兼容性问题不像以前那么严重，但仍然是个问题，特别是如果你无法接受“只要85%的用户能够使用就可以了”。另请参阅：为什么Hello CSS不使用CSS变量。

是否必须选择jQuery

那么你要一直使用jQuery吗？当然不是了。在项目里添加依赖意味着更大的复杂性和更大的文件体积。不过，jQuery本身并不大。经过压缩的默认大小为30K，如果不包含AJAX和其他不常用的东西大小只有23K，如果使用querySelector替代SizzleJS就只剩下17K。对于我来说，30K或者经过优化的17K的jQuery已经能够满足大部分用途。

从Bootstrap移除jQuery的案例可以看出，使用纯JavaScript的代价是很大的：他们重写了辅助函数，去掉了对IE的支持（因为太难了），让API变得不兼容，总共花了一年半的时间。从结果来看，我不觉得它比之前好多少。

我明白他们为什么要那么做。人们希望将Bootstrap和Vue.js放在一起使用，而把jQuery和Vue.js放在一起又显得很奇怪。我也很赞成我们要避免“Web膨胀”，但至少也要务实些。在项目里包含17K的jQuery真的有那么糟糕吗？相比Medium或纽约时报这些动不动就要加载上兆JavaScript的网站，一个17K的jQuery就那么让你难以承受吗？

当然，我们也有一些不使用jQuery的理由：比如你想要写一些会被别人重用的代码或者小函数。但即使是这样，也不至于要拼了老命避免使用jQuery。什么东西都用jQuery来写不是个好主意，但完全不使用jQuery也不是。

我并没有只与jQuery为伍，但它的一些优点确实弥补了JavaScript API的不足。之前的那篇文章建议使用bonzo和$dom，以及其他一些与AJAX有关的包，但它们当中大部分似乎已经停止维护了。另外，既然所有人都会使用jQuery，那么除非非常有必要，否则为什么要用其他东西来替代它？

总结

一些读者可能会想：“那么其他框架呢，比如Vue.js、React”？其实这篇文章的目的在于比较纯JavaScript和jQuery，而不是要和读者讨论什么前端开发大法。

总的来说，使用纯JavaScript也是有理由的，比如我想要开发一个非常快的网站，使用最简单的代码，可以让尽可能多的人访问到。在我看来，服务器端生成的带有“渐进式增强”风格的JavaScript通常是最好的方式。这种开发方式速度快，而且容易，bug更少。

那这是不是意味着Web框架就不是好东西了呢？当然不是了。没有什么东西是非黑即白的，它们一般都存在一系列的权衡（jQuery当然也是）。

我认为，Web是主要是用来浏览 document 的，而不是一个操作系统。尽管对于很多Web APP来说，使用document 方式也可以很好的进行一些操作。

英文原文：https://arp242.net/jquery.html

网友热议

sgift：面对只向用户展示文字的需求，我认为使用现代js框架的理由是：感觉使用html显示页面文本的方式太老土了，他们将文本打包在服务器上的中（它通常以html兼容的形式存在），然后他们将JS推送到浏览器，之后浏览器不得不解释JS之后才能得到html，最后，我才看到了页面的文本信息。而且因为这种方式很慢，我们创造了“服务器端渲染”等技术。当我第一次阅读有关服务器端渲染的内容时，我不明白它是什么，是在服务器上生成了html，并将其发送给客户端吗？新部分是什么？为什么人们将这种作为方式作为web的下一个救星？这简直太疯狂了，我想知道什么时候会停止。

candu：这是在这些讨论中经常被遗忘的部分：它不应该是“SPA（Single Page App，单页应用）为所有东西”也不是“vanilla HTML / CSS / JS for everything”；相反，我们应该使用最合适的工具集。我曾经工作中做过静态网站，为此我通常更多地依赖于vanilla HTML / CSS，并在此处推荐使用JS。我还致力于重型应用，这种方法的局限性很快就会变得明显；在这些情况下，我使用可交互的组件框架，如Vue和React。但也有介于两者之间的方法！对于中型复杂的站点或APPs，我使用了vanilla HTML / CSS / JS，以及一些额外的Python / Makefile管道来生成更多重复的部分。我还使用了混合方法，其中vanilla HTML / CSS / JS用于站点的更多静态部分，Vue用于更动态的部分。您可以在完全SPA模式下使用Vue和“服务器端渲染”…但您也可以像以前一样在服务端生成HTML，然后使用Vue / jQuery /渐进地增强它的一部分的功能。我之前也使用过像Spring这样的“不合时宜”的框架，仅仅因为是客户硬性要求。作为开发人员，我们有责任退后一步，评估手头的任务/团队/环境，并相应地选择工具。

andrei：AT＆T的网站帐户页面仅提供静态HTML。但它们是由js渲染的，我必须等待每次点击后查看加载情况。这是为什么？为什么这么多静态网站和博客都在其所有网页上使用SPA技术？人们疯了吗？如何花费10倍的钱和努力以获得更糟糕的结果？

Carpetsmoker：目前正在处理SPA应用程序无法与FB共享一起使用的情况，因为它会使用一组META / Open Graph标记。所以现在我们回到渲染服务器上的一部分HTML来支持这一点。在JIRA中，如果我在错误的字段中输入，它会向某个地方发布一个帖子并返回一个奇怪的xml页面而我丢失了我的工作。因此，当作者说顶部带有js的经典HTML“更容易开发”时，我傻笑。如果是这样的话，开发人员就不会大量涌向SPA等。这些正是现在的趋势，因为它们更容易开发和维护。让我这样说吧，无论是作为SPA的开发者还是用户，我早就观察到SPA往往需要加载更多的资源，更加困难，更难使用。我不认为这是令人惊讶的，因为“维持状态”是伟大的，但也意味着一旦这种状态横向移动，你的应用程序也会横向移动。这是否描述了每个SPA？不，这是否意味着每个模板应用程序都更好？不是。但平均SPA应用程序是否比普通模板应用程序更差？根据我的经验（虽然我缺乏经验数据）。我不认为流行度是一个很好的评判标准。 jQuery显然不是开发web应用程序的最佳方式 - 这篇文章从来没有打算如此争论，只是为了争辩说它比我最近提倡过的很多vanilla JS更好 - 所以人们去“替代”缺乏jQuery问题的解决方案，但这并不意味着这些解决方案本身不会产生其他问题。我不知道开发web apps的最佳方式是什么，但我知道肯定不是当前的SPA框架。可能某种混合方法，或者尚未发明的完全不同的方法，同时，基于模板的方法更容易理解（可能出错率更小），并且可能是许多网站的最佳方法。

创作场景

为什么 2019 年了我还在用 jQuery