Que utiliser si github n'utilise pas jq ?

Récemment, nous avons complètement supprimé jQuery du code front-end de GitHub.com, ce qui marque la fin de notre processus progressif de suppression progressive de jQuery sur plusieurs années. Cet article décrira comment nous nous appuyions sur jQuery dans le passé, et au fil du temps, nous avons réalisé que nous n'en avions plus besoin, mais au final nous ne l'avons pas remplacé par une autre bibliothèque ou un autre framework, mais avons utilisé un navigateur standard. L'API implémente tout ce que nous besoin.

Au début, jQuery signifiait beaucoup pour nous

GitHub.com a commencé à utiliser jQuery 1.2.1 fin 2007. C'était un an avant que Google ne lance son navigateur Chrome. Il n'existait aucun moyen standard d'interroger les éléments DOM via des sélecteurs CSS, ni de restituer dynamiquement le style d'un élément, et l'interface XMLHttpRequest d'Internet Explorer, comme de nombreuses autres API, souffrait d'incohérences entre les navigateurs.

jQuery facilite la manipulation du DOM, la création d'animations et de requêtes "AJAX". En gros, il permet aux développeurs Web de créer des expériences Web plus modernes et dynamiques. Mieux encore, le code développé avec jQuery pour un navigateur fonctionnera également dans d'autres navigateurs. Au début de GitHub, jQuery permettait à de petites équipes de développement de prototyper et de développer rapidement de nouvelles fonctionnalités sans avoir à adapter le code spécifiquement à chaque navigateur Web.

La bibliothèque d'extensions construite sur la base de l'interface simple de jQuery est également devenue l'élément de base du front-end de GitHub.com : pjax (https://github.com/defunkt/jquery-pjax) et facebox ( https://github.com/defunkt/facebox).

Nous n'oublierons jamais John Resig et les contributeurs jQuery pour la création et la maintenance d'une bibliothèque aussi utile et essentielle.

Standards Web ultérieurs

Au fil des années, GitHub est devenue une entreprise comptant des centaines d'ingénieurs et a progressivement établi une équipe dédiée responsable du développement du code JavaScript. qualité. Nous avons exclu la dette technique, et parfois la dette technique augmente avec des dépendances qui nous donnent une certaine valeur au début, mais cette valeur diminue également avec le temps.

Nous pouvons comparer jQuery à l'évolution rapide des standards du Web pris en charge par les navigateurs modernes :

Le modèle $(selector) peut être remplacé à l'aide de querySelectorAll();

Element.classList peut désormais être utilisé pour implémenter le changement de nom de classe CSS ;

CSS prend désormais en charge la définition d'animations visuelles dans les feuilles de style au lieu de JavaScript

peut désormais être utilisé. Fetch Standard exécute $ ; Requêtes .ajax ;

l'interface addEventListener() est suffisamment stable et peut être utilisée sur toutes les plates-formes

Nous pouvons utiliser des bibliothèques légères pour encapsuler des modèles de délégation d'événements

Avec le développement ; du langage JavaScript, une partie du sucre syntaxique fourni par jQuery est devenue redondante.

De plus, la syntaxe de la chaîne ne satisfait pas à la façon dont nous voulons écrire du code.

Enfin, nous avons commencé à utiliser Flow pour annoter les types afin d'effectuer une vérification de type statique au moment de la construction, et nous avons constaté que la syntaxe de chaîne n'est pas adaptée à l'analyse statique car presque toutes les méthodes jQuery renvoient le même type. Nous avons choisi Flow à l'époque car des fonctionnalités telles que le mode faible @flow nous permettaient d'appliquer progressivement des types à notre base de code non typé.

Dans l'ensemble, la suppression de jQuery signifie que nous pouvons nous appuyer davantage sur les standards Web, faire de la documentation Web MDN la documentation par défaut de facto pour les développeurs front-end, maintenir un code plus résilient à l'avenir et réduire les dépendances de 30 Ko. sont supprimés de nos offres groupées, accélérant ainsi le chargement des pages et l'exécution de JavaScript.

Éléments personnalisés

Une nouvelle technologie qui a été en vogue ces dernières années est celle des éléments personnalisés - une bibliothèque de composants native du navigateur, ce qui signifie que les utilisateurs n'ont pas besoin de télécharger , analysant et compilant des octets supplémentaires.

À partir de 2014, nous avons créé des éléments personnalisés basés sur la spécification v0. Cependant, comme les normes évoluent encore, nous n’y avons pas consacré beaucoup d’efforts. Ce n'est qu'en 2017, lorsque la spécification Web Components v1 a été publiée et que Chrome et Safari l'ont implémentée, que nous avons commencé à adopter plus largement les éléments personnalisés.

Lors de la suppression de jQuery, nous étudions également des modèles d'extraction d'éléments personnalisés. Par exemple, nous convertissons la facebox utilisée pour afficher une boîte de dialogue modale en un élément (https://github.com/github/details-dialog-element).

Notre philosophie d'amélioration progressive s'étend également aux éléments personnalisés. Cela signifie que nous conserverons autant de contenu du balisage que possible avant d'ajouter un comportement au balisage. Par exemple, affiche l'horodatage d'origine par défaut, qui est mis à niveau pour convertir l'heure dans le fuseau horaire local, tandis que pour , lorsqu'il est intégré dans un élément

Interactif sans utiliser JavaScript, il a été mis à niveau avec des améliorations d'accessibilité.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!