GitHub: なぜ jQuery を廃止するのですか?

最近、私たちは GitHub.com のフロントエンド コードから jQuery を完全に削除しました。これは、数年かけて徐々に jQuery を削除するプロセスの終わりを意味します。この記事では、過去にどのように jQuery に依存していたか、時間が経つにつれて jQuery が必要なくなったことに気づきましたが、最終的には別のライブラリやフレームワークに置き換えず、標準のブラウザーを使用したことについて説明します。API は、私たちが実行するすべてのものを実装します。必要。
初期の頃、jQuery は私たちにとって大きな意味を持っていました

GitHub.com は、Google が Chrome ブラウザをリリースする 1 年前の 2007 年末に jQuery 1.2.1 の使用を開始しました。 CSS セレクターを介して DOM 要素をクエリしたり、要素のスタイルを動的にレンダリングしたりする標準的な方法はなく、他の多くの API と同様に、Internet Explorer の XMLHttpRequest インターフェイスにはブラウザ間の不一致が発生していました。

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 クラス名の切り替えを実装できるようになりました。 JavaScript の代わりにスタイルシートでのビジュアル アニメーションの定義をサポートします。
Fetch Standard を使用して $.ajax リクエストを実行できるようになりました。
addEventListener() インターフェイスは、クロスプラットフォームでの使用に十分安定しています。
軽量のライブラリを使用してイベント委任をカプセル化できます。パターン;
JavaScript 言語の発展に伴い、jQuery が提供する構文糖の一部が冗長になりました。
また、チェーン構文は、私たちが望むコードの書き方を満たしていません。例:

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

この構文は簡単に書くことができますが、私たちの基準によれば、私たちの意図をあまりうまく伝えていません。作成者は現在のページに 1 つ以上の js-widget 要素を期待していますか?また、ページのマークアップを更新し、誤って js-widget クラス名を省略した場合、ブラウザは何が問題だったかを示す例外をスローしますか?デフォルトでは、セレクターに一致するものがない場合、jQuery は式全体をスキップしますが、私たちにとって、これはバグでした。

最後に、フローを使用して型に注釈を付けて、ビルド時に静的型チェックを実行し始めましたが、ほとんどすべての jQuery メソッドが同じ型の結果を返すため、チェーン構文は静的分析には適していないことがわかりました。当時私たちが Flow を選択したのは、@flow 弱モードのような機能により、型なしのコード ベースに型を段階的に適用できるためです。

結局のところ、jQuery を削除するということは、Web 標準への依存度を高め、MDN Web ドキュメントをフロントエンド開発者にとっての事実上のデフォルトのドキュメントにし、将来的により回復力のあるコードを維持し、削除されたファイルから 30 KB の依存関係を削除できることを意味します。ページの読み込みと JavaScript の実行を高速化するバンドル。

段階的な分離

最終的な目標を設定しましたが、jQuery を削除するためにすべてのリソースを一度に割り当てるのが現実的ではないこともわかっています。この性急なアプローチは、Web サイトの機能の低下につながる可能性があります。代わりに、次の戦略を採用しました:

1. 设定指标，跟踪整一行代码调用 jQuery 的比率，并监控指标走势随时间变化的情况，确保它保持不变或下降，而不是上升。
2. 我们不鼓励在任何新代码中导入 jQuery。为了方便自动化，我们创建了 eslint-plugin-jquery（https://github.com/dgraham/eslint-plugin-jquery），如果有人试图使用 jQuery 功能，例如 $.ajax，CI 检查将会失败。
3. 旧代码中存在大量违反 eslint 规则的情况，我们在代码注释中使用特定的 eslint-disable 规则进行了注解。看到这些代码的读者，他们都该知道，这些代码不符合我们当前的编码实践。
4. 我们创建了一个拉请求机器人，当有人试图添加新的 eslint-disable 规则时，会对拉取请求留下评论。这样我们就可以尽早参与代码评审，并提出替代方案。
5. 很多旧代码使用了 pjax 和 facebox 插件，所以我们在保持它们的接口几乎不变的同时，在内部使用 JS 重新实现它们的逻辑。静态类型检查有助于提升我们进行重构的信心。
6. 很多旧代码与 rails-behavior 发生交互，我们的 Ruby on Rails 适配器几乎是“不显眼的”JS，它们将 AJAX 生命周期处理器附加到某些表单上：

// 旧方法
  $(document).on('ajaxSuccess', 'form.js-widget', function(event, xhr, settings, data) {
    // 将响应数据插入到 DOM 中
  })

7. 我们选择触发假的 ajax* 生命周期事件，并保持这些表单像以前一样异步提交内容，而不是立即重写所有调用，只是会在内部使用 fetch()。
8. 我们自己维护了 jQuery 的一个版本，每当发现我们不再需要 jQuery 的某个模块的时候，就会将它从自定义版本中删除，并发布更轻量的版本。例如，在移除了 jQuery 的 CSS 伪选择器之后（如:visible 或:checkbox）我们就可以移除 Sizzle 模块了，当所有的 $.ajax 调用都被 fetch() 替换时，就可以移除 AJAX 模块。
这样做有两个目的：加快 JavaScript 执行速度，同时确保不会有新代码试图使用已移除的功能。
9. 我们根据网站的分析结果尽快放弃对旧版本 Internet Explorer 的支持。每当某个 IE 版本的使用率低于某个阈值时，我们就会停止向它提供 JavaScript 支持，并专注支持更现代的浏览器。尽早放弃对 IE 8 和 IE 9 的支持对于我们来说意味着可以采用很多原生的浏览器功能，否则的话有些功能很难通过 polyfill 来实现。
10. 作为 GitHub.com 前端功能开发新方法的一部分，我们专注于尽可能多地使用常规 HTML，并且逐步添加 JavaScript 行为作为渐进式增强。因此，那些使用 JS 增强的 Web 表单和其他 UI 元素通常也可以在禁用 JavaScript 的浏览器上正常运行。在某些情况下，我们可以完全删除某些遗留的代码，而不需要使用 JS 重写它们。

经过多年的努力，我们逐渐减少对 jQuery 的依赖，直到没有一行代码引用它为止。

自定义元素

近年来一直在炒作一项新技术，即自定义元素——浏览器原生的组件库，这意味着用户无需下载、解析和编译额外的字节。

从 2014 年开始，我们已经基于 v0 规范创建了一些自定义元素。然而，由于标准仍然在不断变化，我们并没有投入太多精力。直到 2017 年，Web Components v1 规范发布，并且 Chrome 和 Safari 实现了这一规范，我们才开始更广泛地采用自定义元素。

在移除 jQuery 期间，我们也在寻找用于提取自定义元素的模式。例如，我们将用于显示模态对话框的 facebox 转换为元素（https://github.com/github/details-dialog-element）。

我们的渐进式增强理念也延伸到了自定义元素上。这意味着我们将尽可能多地保留标记内容，然后再标记上添加行为。例如，默认显示原始时间戳，它被升级成可以将时间转换为本地时区，而对于，当它被嵌在

元素中时，可以在不使用 JavaScript 的情况下具备交互性，它被升级成具有辅助增强功能。

以下是实现自定义元素的示例：

// local-time 根据用户的当前时区显示时间。
//
// 例如:
//   <local-time datetime="2018-09-06T08:22:49Z">Sep 6, 2018</local-time>
//
class LocalTimeElement extends HTMLElement {
  static get observedAttributes() {
    return [&#39;datetime&#39;]
  }
  attributeChangedCallback(attrName, oldValue, newValue) {
    if (attrName === &#39;datetime&#39;) {
      const date = new Date(newValue)
      this.textContent = date.toLocaleString()
    }
  }
}
if (!window.customElements.get(&#39;local-time&#39;)) {
  window.LocalTimeElement = LocalTimeElement
  window.customElements.define(&#39;local-time&#39;, LocalTimeElement)
}

我们很期待 Web 组件的 Shadow DOM。Shadow DOM 的强大功能为 Web 带来了很多可能性，但也让 polyfill 变得更加困难。因为使用 polyfill 会导致性能损失，因此在生产环境中使用它们是不可行的。

以上がGitHub: なぜ jQuery を廃止するのですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。