为什么2019年了我还在用jQuery

源自 | Hacker News

译者 | 无明

编辑 | 王莹

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

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

文章链接： http://youmightnotneedjquery.com/

使用 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 变量，详见： https://arp242.net/css-vars.html。

是否必须选择 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，那么除非非常有必要，否则为什么要用其他东西来替代它？

相关链接：

bonzo： https://github.com/ded/bonzo

$dom： https://github.com/julienw/dollardom

总结

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

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

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

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

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

 网友热议

面对只向用户展示文字的需求，我认为使用现代 js 框架的理由是：感觉使用 html 显示页面文本的方式太老土了，他们将文本打包在服务器上的中（它通常以 html 兼容的形式存在），然后将 JS 推送到浏览器，之后浏览器不得不解释 JS 之后才能得到 html，最后，文本信息才显示在页面上。

因为这种方式很慢，我们创造了“服务器端渲染”等技术。当我第一次阅读有关服务器端渲染的内容时，我不明白它是什么，是在服务器上生成了 html，并将其发送给客户端吗？新功能亮点是什么？为什么人们将这种作为方式作为 web 的下一个救星？这简直太疯狂了，我想知道什么时候会停止。

— sgift

这是在这些讨论中经常被遗忘的部分：它不应该是“SPA（Single Page App，单页应用）为所有东西”也不是“vanilla HTML / CSS / JS for everything”；相反，我们应该使用最合适的工具集。

我曾经工作中做过静态网站，为此我通常更多地依赖于 vanilla HTML / CSS，并在此处推荐使用 JS。我还致力于重型应用，这种方法的局限性很快就会变得明显；在这些情况下，我使用可交互的组件框架，如 Vue 和 React。

但也有介于两者之间的方法！对于中型复杂的站点或 APP，我使用了 vanilla HTML / CSS / JS，以及一些额外的 Python / Makefile 管道来生成更多重复的部分。我还使用了混合方法，其中 vanilla HTML / CSS / JS 用于站点的更多静态部分，Vue 用于更动态的部分。你可以在完全 SPA 模式下使用 Vue 和“服务器端渲染”... 但你也可以像以前一样在服务端生成 HTML，然后使用 Vue / jQuery / 渐进地增强它的部分功能。

我之前也使用过像 Spring 这样的“不合时宜”的框架，仅仅因为是客户硬性要求。作为开发人员，我们有责任退后一步，评估手头的任务 / 团队 / 环境，并相应地选择工具。

— candu

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

— andrei

当作者说顶部带有 js 的经典 HTML“更容易开发”时，我傻笑。如果是这样的话，开发人员就不会大量涌向 SPA 等。这正是现在的趋势，因为它们更容易开发和维护。

让我这样说吧，无论是作为 SPA 的开发者还是用户，我早就观察到 SPA 往往需要加载更多的资源，更加困难，更难使用。我不认为这是奇怪的，因为“维持状态”是伟大的，但也意味着一旦这种状态横向移动，你的应用程序也会横向移动。

这是否描述了每个 SPA？不，这是否意味着每个模板应用程序都更好？不是。但平均 SPA 应用程序是否比普通模板应用程序更差？根据我的经验（虽然我缺乏经验数据）。我不认为流行度是一个很好的评判标准。 jQuery 显然不是开发 web 应用程序的最佳方式 - 这篇文章从来没有打算如此争论，只是为了争辩说它比我最近提倡过的 vanilla JS 更好 - 所以人们去“替代” jQuery 的解决方案，并不意味着这些解决方案本身不会产生其他问题。

我不知道开发 web apps 的最佳方式是什么，但我知道肯定不是当前的 SPA 框架。可能某种混合方法，或者尚未发明的方法，同时，基于模板的方法更容易理解（可能出错率更小），并且可能是许多网站的最佳方法。

—— Carpetsmoker

福利时间

6 月 20 日 13:30-18:00，2019 GMTC 北京·全球大前端技术大会【多端提效与质量优化实践专场】。一个专场，听尽极限性能优化，Node 服务稳定性实践，Native、Flutter、JS 等多场景下的质量监控预警以及快速定位问题方法。全方位带你学习一线大厂的实践经验，多角度进阶大前端开发技能。扫描下方二维码或点击【阅读原文】限时免费报名，先到先得～