比来，我们将 jQuery 完全从 GitHub.com 的前端代码中移除了，这标识表记标帜着我们数年来逐步移除 jQuery 这个渐进式的过程终于结束了，这对我们来说是一件里程碑式的事件。这篇文章将介绍过去我们是如何依赖上 jQuery 的，跟着时间地推移，我们意识到不再需要它，但到最后我们并没有使用另一个库或框架代替它，而是使用标准的浏览器 API 实现了我们所需要的一切。

早期，jQuery 对我们意义重大

GitHub.com 在 2007 年底开始使用 jQuery 1.2.1，那是谷歌颁布 Chrome 浏览器的前一年。其时还没有通过 CSS 选择器来盘问 DOM 元素的标准要领，也没有动态衬着元素的样式的标准要领，而 Internet Explorer 的 XMLHttpRequest 接口与其他很多 API 一样，在浏览器之间存在不一致性问题。

jQuery 让 DOM 操纵、创建动画和“AJAX”请求变得相当简单，根基上，它让 Web 开发人员能够创建越发现代化的动态 Web 体验。最重要的是，使用 jQuery 为一个浏览器开发的代码也适用于其他浏览器。在 GitHub 的早期阶段，jQuery 让小型的开发团队能够快速进行原型设计并开发出新成果，而无需专门针对每个 Web 浏览器调解代码。

基于 jQuery 简单的接口所构建的扩展库也成为 GitHub.com 前真个根本构建块：pjax（https://github.com/defunkt/jquery-pjax）和 facebox（https://github.com/defunkt/facebox）。

我们将永远不会忘记 John Resig 和 jQuery 孝敬者创建和维护的这样一个有用的根基库。

后来的 Web 标准

多年来，GitHub 生长为一家拥有数百名工程师的公司，并逐渐创立了一个专门的团队，卖力 JavaScript 代码的规模和质量。我们一直在排除技术债务，有时技术债务会跟着依赖项的增多而增长，这些依赖项在一开始会为我们带来必然的价值，但这些价值也跟着时间的推移而下降。

我们可以将 jQuery 与现代浏览器撑持的 Web 标准的快速演化进行对照：

$(selector) 模式可以使用 querySelectorAll() 来替换；

此刻可以使用 Element.classList 来实现 CSS 类名切换；

CSS 此刻撑持在样式表中而不是在 JavaScript 中界说可视动画；

此刻可以使用 Fetch Standard 执行 $.ajax 请求；

addEventListener() 接口已经足够不变，可以跨平台使用；

我们可以使用轻量级的库来封装事件委托模式；

跟着 JavaScript 语言的成长，jQuery 供给的一些语法糖已经变得多余。

此外，链式语法不能满足我们想要的编写代码的方法。例如：

$(‘.js-widget‘)
.addClass(‘is-loading‘)
.show()

这种语法写起来很简单，但是按照我们的标准，它并不能很好地转达我们的意图。作者是否期望在当前页面上有一个或多个 js-widget 元素？此外，如果我们更新页面符号并不测遗漏了 js-widget 类名，浏览器是否会抛出异常会报告我们出了什么问题？默认情况下，当没有任何内容与选择器匹配时，jQuery 会跳过整个表达式，但对我们来说，这是一个 bug。

最后，我们开始使用 Flow 来注解类型，以便在构建时执行静态类型查抄，并且我们发明，链式语法不适合做静态分析，因为几乎所有 jQuery 要领返回的功效都是不异的类型。我们其时之所以选择 Flow，是因为 @flow weak 模式等成果可以让我们逐步将类型应用于无类型的代码库上。

总而言之，移除 jQuery 意味着我们可以更多地依赖 Web 标准，让 MDN Web 文档成为前端开发人员事实上的默认文档，在将来可以维护更具弹性的代码，并且可以将 30KB 的依赖从我们的绑缚包中移除，加快页面的加载速度和 JavaScript 的执行速度。

逐步解耦

虽然定下了最终方针，但我们也知道，分配所有资源一次性移除 jQuery 是不成行的。这种仓皇忙忙的做法可能会导致网站成果呈现回归。相反，我们采纳了以下的计谋：

1. 设定指标，跟踪整一行代码挪用 jQuery 的比率，并监控指标走势随时间变革的情况，确保它连结不乱或下降，而不是上升。

2. 我们不鼓励在任何新代码中导入 jQuery。为了便利自动化，我们创建了 eslint-plugin-jquery（https://github.com/dgraham/eslint-plugin-jquery），如果有人试图使用 jQuery 成果，例如 $.ajax，CI 查抄将会掉败。

3. 旧代码中存在大量违反 eslint 法则的情况，我们在代码注释中使用特定的 eslint-disable 法则进行了注解。看到这些代码的读者，他们都该知道，这些代码不切合我们当前的编码实践。

4. 我们创建了一个拉请求机器人，当有人试图添加新的 eslint-disable 法则时，会对拉取请求留下评论。这样我们就可以尽早参预代码评审，并提出替代方案。