Was ist zu verwenden, wenn Github JQ nicht verwendet?

Vor Kurzem haben wir jQuery vollständig aus dem Front-End-Code von GitHub.com entfernt. Dies markiert das Ende unseres schrittweisen Prozesses, jQuery über mehrere Jahre hinweg schrittweise zu entfernen. In diesem Artikel wird beschrieben, wie wir uns in der Vergangenheit auf jQuery verlassen haben und mit der Zeit festgestellt haben, dass wir es nicht mehr benötigen. Am Ende haben wir es jedoch nicht durch eine andere Bibliothek oder ein anderes Framework ersetzt, sondern einen Standardbrowser verwendet. Die API implementiert alles, was wir tun brauchen.

In den frühen Tagen bedeutete uns jQuery sehr viel

GitHub.com begann mit der Verwendung von jQuery 1.2.1 Ende 2007. Das war ein Jahr bevor Google seinen Chrome-Browser veröffentlichte. Es gab keine Standardmethode zum Abfragen von DOM-Elementen über CSS-Selektoren oder zum dynamischen Rendern des Stils eines Elements, und die XMLHttpRequest-Schnittstelle des Internet Explorers litt wie viele andere APIs unter Inkonsistenzen zwischen Browsern.

jQuery macht es einfach, DOM zu manipulieren, Animationen und „AJAX“-Anfragen zu erstellen, im Grunde ermöglicht es Webentwicklern, modernere und dynamischere Weberlebnisse zu erstellen. Das Beste daran ist, dass mit jQuery für einen Browser entwickelter Code auch in anderen Browsern funktioniert. In den Anfängen von GitHub ermöglichte jQuery kleinen Entwicklungsteams, schnell Prototypen zu erstellen und neue Funktionen zu entwickeln, ohne den Code speziell für jeden Webbrowser anpassen zu müssen.

Die auf der einfachen Schnittstelle von jQuery basierende Erweiterungsbibliothek ist auch zum Grundbaustein des GitHub.com-Frontends geworden: pjax (https://github.com/defunkt/jquery-pjax) und Facebox ( https://github.com/defunkt/facebox).

Wir werden John Resig und die jQuery-Mitwirkenden nie vergessen, weil sie eine so nützliche und wichtige Bibliothek erstellt und gepflegt haben.

Spätere Webstandards

Im Laufe der Jahre entwickelte sich GitHub zu einem Unternehmen mit Hunderten von Ingenieuren und baute nach und nach ein engagiertes Team auf, das für die Entwicklung von JavaScript-Code verantwortlich ist Qualität. Wir haben technische Schulden ausgeschlossen, und manchmal wachsen technische Schulden mit Abhängigkeiten, die uns am Anfang einen gewissen Wert verschaffen, aber dieser Wert nimmt mit der Zeit auch ab.

Wir können jQuery mit der schnellen Entwicklung von Webstandards vergleichen, die von modernen Browsern unterstützt werden:

Das $(selector)-Muster kann durch querySelectorAll();

Element.classList kann jetzt zum Implementieren des CSS-Klassennamenwechsels verwendet werden.

CSS unterstützt jetzt das Definieren visueller Animationen in Stylesheets anstelle von JavaScript.

kann jetzt verwendet werden. Fetch Standard führt $ aus .ajax-Anfragen;

Die Schnittstelle addEventListener() ist stabil genug und kann plattformübergreifend verwendet werden.

Mit der Entwicklung können wir leichtgewichtige Bibliotheken verwenden In der JavaScript-Sprache ist ein Teil des von jQuery bereitgestellten Syntaxzuckers überflüssig geworden.

Außerdem entspricht die Kettensyntax nicht der Art und Weise, wie wir Code schreiben möchten.

Schließlich haben wir begonnen, Flow zum Annotieren von Typen zu verwenden, um eine statische Typprüfung zur Erstellungszeit durchzuführen, und haben festgestellt, dass die Kettensyntax nicht für die statische Analyse geeignet ist, da fast alle jQuery-Methoden denselben Ergebnistyp zurückgeben. Wir haben uns damals für Flow entschieden, weil Funktionen wie der @flow-Schwachmodus es uns ermöglichten, nach und nach Typen auf unsere untypisierte Codebasis anzuwenden.

Alles in allem bedeutet das Entfernen von jQuery, dass wir uns stärker auf Webstandards verlassen können, die MDN-Webdokumentation de facto zur Standarddokumentation für Front-End-Entwickler machen, in Zukunft stabileren Code beibehalten und die 30-KB-Abhängigkeiten reduzieren können werden aus unseren Paketen entfernt, wodurch das Laden der Seite und die Ausführung von JavaScript beschleunigt werden.

Eine neue Technologie, die in den letzten Jahren gehypt wurde, sind benutzerdefinierte Elemente – eine Komponentenbibliothek, die nativ für den Browser ist, was bedeutet, dass Benutzer keinen Download durchführen müssen , Parsen und Kompilieren zusätzlicher Bytes.

Ab 2014 haben wir einige benutzerdefinierte Elemente basierend auf der v0-Spezifikation erstellt. Da sich die Standards jedoch immer noch ändern, haben wir uns nicht viel Mühe gegeben. Erst 2017, als die Web Components v1-Spezifikation veröffentlicht und in Chrome und Safari implementiert wurde, begannen wir, benutzerdefinierte Elemente breiter zu übernehmen.

Während der Entfernung von jQuery prüfen wir auch Muster zum Extrahieren benutzerdefinierter Elemente. Beispielsweise konvertieren wir die Facebox, die zum Anzeigen eines modalen Dialogs verwendet wird, in ein -Element (https://github.com/github/details-dialog-element).

Unsere Philosophie der progressiven Verbesserung erstreckt sich auch auf kundenspezifische Elemente. Das bedeutet, dass wir so viel Markup-Inhalt wie möglich beibehalten, bevor wir Verhalten zum Markup hinzufügen. Beispielsweise zeigt standardmäßig den ursprünglichen Zeitstempel an, der aktualisiert wird, um die Zeit in die lokale Zeitzone umzuwandeln, während dies für möglich ist, wenn er in ein