2019 年了 ，jQuery 过时了吗？【黑马web前端】

许多人都倡议说，“用 Vanilla JS 吧，你并不需要 jQuery。” 当然，我们的确不需要太多的东西，不管它有多好。我也不需要 jQuery，尽管它相当不错！

有一个 网页 专门讲述了“为什么你可能不需要 jQuery 。” 它试图兜售的一种思想是 “jQuery 很容易将人们带到沟里去”。但是，使用 jQuery 最好的理由之一就是：一行简单的 jQuery 代码能代替 10行 Vanilla JS 代码。

我认为许多 JS API，尤其是 DOM API 很差劲，因为它们有违人的审美。el.insertAdjacentElement('afterend', other) 这行代码可能不会生效，但是 $(el).after(other) 却总是赏心悦目。虽然我并不喜欢 $() 函数的外观，但它带给我们的体验比 DOM 好多了。

如何快速获取一个元素的兄弟节点呢？用 nextSibling 或者 nextElementSibling 吗？它们的区别是什么？哪些游览器又支持哪种方法呢？当人们为了搞明白这些疑惑而忙于查阅 MDN 时，我很确信在 jQuery 中，我们只需要使用 next() 或者 prev() 即可。

许多常用的操作在标准的 JS API 中显得很拙劣，这里我们可以列出一个清单，在那篇 “你可能不需要 jQuery ” 的网页中，它正好干了一件这样的漂亮事！

对于各种常见的任务，你仍然需要查看帮助函数。 “你可能不需要 jQuery ” 的网页列举了不少这样的例子。你应该选择标准的解决方案就是使用 jQuery ，而不是每次需要用的时候从 Stack Overflow 的答案中粘贴复制。

虽然浏览器兼容性不再是一个问题，但对 Vanil JS 仍然是个问题，尤其是当你不属于那 85% 大众之列时：

如果它对全世界85%的人都有效，那么它对我来说就足够好了。

这里可以参考这篇文章： 为什么 Hello CSS 不使 CSS 变量 。

你应该使用 jQuery 吗？当然不。添加任何依赖都是以复杂性和增加文件尺寸为代价的，所幸 jQuery 的文件并不大：压缩后它默认的构建为 30K，一个不包含 ajax 的定制构建却能高达 23K，而用 querySelector 替代 SizzleJS 构建的文件仅有 17K 。为了使用 jQuery 实现某个功能，无论是原始的 30K，还是优化后的 17K 都是在可接受范围内的。

你可以看看 Bootstrap removing jQuery 这个项目，以此为例，了解一下使用 vanilla JS 需要费多大的劲：他们必须写自己的帮助器；因为太难添加而不得不放弃对 IE 浏览器的支持；API 设计得并不兼容，而且已经花了一年半的时间将 jQuery 替换成 Vanilla JS 。结果怎么样呢？我只能说这个项目看起来效果并不好。

我明白他们这么做的原因，是的，人们想要在 Vue.js 中使用 Bootstrap，而同时使用 Vue.js 和 jQuery 看起来又有一点愚蠢诸如此类的等等原因，让他们耗费气力地将 jQuery 从 Bootstrap 中移除。

人们有很多理由说服自己不使用 jQuery ：比如，你想代码复用，或者写的仅仅是一个小函数。然而，我们要尽量避免 jQuery 吗？答案是否定的。这么好的东西为什么不用呢！jQuery 满屏飞（jQuery all the things）可能不是个好主意，但是完全摒弃 jQuery 也不好吧。

有些读者可能会疑惑 “ Vue.js 、React 、或者其他流行框架怎么样呢？” 本文旨在比较 Vanilla JavaScript 和 jQuery，我也并没有打算详细介绍前端开发的原理。

前文已经表示过，我认为我们没有理由固守简单的 JavaScript ，主要是我想快速地构建网页、使用最简单合适的代码、并且尽可能地能被大多数人访问到。依我的经验，服务端生成模版，加上“渐进式增强”样式的 JavaScript 的点缀，通常是达到上述目的的最好方法。它通常更容易开发，速度更快，bug 更少，而且你的笔记本电脑的风扇也不会吵醒邻居。

这意味着那些前端框架都不好吗？也不是，没有绝对的好坏之分，但通常需要做一些权衡。（显然，jQuery 也是如此。）

总的来说，我认为 Web 是一个用于浏览文档的系统，而不是操作系统。对大多数 Web 应用来说，一个文档化的方案会运作得更好。（也许在将来，这是一个值得再探讨的新话题）

我知道你能用 jQuery(sel) 或者 window.jq = jQuery ，但我不是在真空中编程，我更喜欢标准代码，无论好坏，在 jQuery 中做所有事情的标准操作就是 $。