GitHub: jQuery를 더 이상 사용하지 않는 이유는 무엇입니까?

최근에 우리는 GitHub.com의 프런트 엔드 코드에서 jQuery를 완전히 제거했습니다. 이는 수년에 걸쳐 점진적으로 jQuery를 제거하는 과정이 끝났음을 의미합니다. 이 기사에서는 과거에 jQuery에 어떻게 의존했는지 설명하고 시간이 지남에 따라 더 이상 필요하지 않다는 것을 깨달았지만 결국 다른 라이브러리나 프레임워크로 교체하지 않고 표준 브라우저를 사용했습니다. API는 우리가 구현하는 모든 것을 구현합니다. 필요.
jQuery는 초기에 우리에게 큰 의미가 있었습니다

GitHub.com은 Google이 Chrome 브라우저를 출시하기 1년 전인 2007년 후반에 jQuery 1.2.1을 사용하기 시작했습니다. CSS 선택기를 통해 DOM 요소를 쿼리하거나 요소의 스타일을 동적으로 렌더링하는 표준 방법이 없었으며 Internet Explorer의 XMLHttpRequest 인터페이스는 다른 많은 API와 마찬가지로 브라우저 간의 불일치로 인해 어려움을 겪었습니다.

jQuery를 사용하면 DOM 조작, 애니메이션 및 "AJAX" 요청 생성이 놀라울 정도로 쉬워집니다. 기본적으로 이를 통해 웹 개발자는 보다 현대적이고 동적인 웹 경험을 만들 수 있습니다. 무엇보다도, 한 브라우저용으로 jQuery로 개발된 코드는 다른 브라우저에서도 작동합니다. GitHub 초창기에는 jQuery를 사용하여 소규모 개발 팀이 각 웹 브라우저에 맞게 코드를 맞춤화하지 않고도 신속하게 프로토타입을 만들고 새로운 기능을 개발할 수 있었습니다.

jQuery의 간단한 인터페이스를 기반으로 구축된 확장 라이브러리는 GitHub.com 프런트 엔드의 기본 빌딩 블록이기도 합니다: pjax(https://github.com/defunkt/jquery-pjax) 및 Facebook(https:// github.com/defunkt/facebox).

이렇게 유용하고 필수적인 라이브러리를 만들고 유지 관리한 John Resig와 jQuery 기여자를 결코 잊지 않을 것입니다.

최신 웹 표준

수년에 걸쳐 GitHub는 수백 명의 엔지니어를 보유한 회사로 성장했으며 점차 JavaScript 코드의 규모와 품질을 담당하는 전담 팀을 구성했습니다. 우리는 기술 부채를 제외해 왔으며 때로는 기술 부채가 초기에 우리에게 어느 정도 가치를 제공하는 종속성과 함께 커지지만 시간이 지남에 따라 그 가치도 감소합니다.

jQuery를 최신 브라우저에서 지원하는 웹 표준의 급속한 발전과 비교할 수 있습니다.
$(selector) 패턴은 querySelectorAll()을 사용하여 대체할 수 있습니다.
Element.classList는 이제 CSS 클래스 이름 전환을 구현하는 데 사용할 수 있습니다. JavaScript 대신 스타일시트에서 시각적 애니메이션 정의를 지원합니다.
addEventListener() 인터페이스는 크로스 플랫폼 사용에 충분히 안정적입니다.
이벤트 위임을 캡슐화할 수 있습니다.
JavaScript 언어가 개발되면서 jQuery에서 제공하는 일부 구문 설탕이 중복되었습니다.
또한 체인 구문은 우리가 원하는 코드 작성 방식을 만족시키지 않습니다. 예를 들면 다음과 같습니다.

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

이 구문은 작성하기는 간단하지만 우리의 기준에 따르면 우리의 의도를 잘 전달하지 못합니다. 작성자가 현재 페이지에 하나 이상의 js-widget 요소를 기대합니까? 또한 페이지 마크업을 업데이트하고 실수로 js-widget 클래스 이름을 생략한 경우 브라우저에서 무엇이 잘못되었는지 알려주는 예외를 발생시키나요? 기본적으로 jQuery는 선택기와 일치하는 항목이 없으면 전체 표현식을 건너뛰지만 우리에게는 이것이 버그였습니다.

마지막으로 우리는 빌드 시 정적 유형 검사를 수행하기 위해 유형에 주석을 달기 위해 Flow를 사용하기 시작했으며 거의 ​​모든 jQuery 메서드가 동일한 유형의 결과를 반환하기 때문에 체인 구문이 정적 분석에 적합하지 않다는 것을 발견했습니다. 당시 우리는 @flow 약한 모드와 같은 기능을 통해 유형이 지정되지 않은 코드 기반에 유형을 점진적으로 적용할 수 있었기 때문에 Flow를 선택했습니다.

대체로 jQuery를 제거한다는 것은 웹 표준에 더 많이 의존하고, MDN 웹 문서를 프런트엔드 개발자를 위한 사실상의 기본 문서로 만들고, 향후 더 탄력적인 코드를 유지하고, 제거된 코드에서 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 规则时，会对拉取请求留下评论。这样我们就可以尽早参与代码评审，并提出替代方案。
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 중국어 웹사이트의 기타 관련 기사를 참조하세요!