许多人倡导“只采用纯 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 提供更多的表达式要快得多。
tSibling 还是 nextElementSibling？它有什么不一样吗？什么样应用程序全力支持它？又或是不全力支持？为了读懂那些，你须要读懂或是去翻查 MDN，但假如采用了 jQuery，只须要初始化 next() 或是 prev() 方式。
JavaScript API 提供更多的许多国际标准操作方式都很怪异，我原本能列举许多，不过下面提及的那篇该文已经列举了一小部分了。
你可能将还须要许多远距表达式来顺利完成许多常用的各项任务，反之亦然，前述的该文也列举了许多这样的表达式。而 jQuery 就包涵了那些小东西，免得你四处复本黏贴这类标识符。
虽然现在应用程序兼容难题Deoria从前所以轻微，但依然是个难题，不光是假如你难以拒绝接受“如果 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 等多场景下的质量监控预警以及快速定位难题方式。全方位带你学习一线大厂的实践经验，多角度进阶大前端开发技能。扫描上方二维
