Share
La plupart d’entre nous connaissons bien la bibliothèque JavaScript jQuery et l’utilisons probablement dans au moins certains de nos projets. Mais que savons-nous des personnes qui consacrent inlassablement leur temps à la maintenance de la bibliothèque JavaScript la plus populaire du Web? J'ai récemment eu la chance d'interviewer le chef de l'équipe principale de jQuery, Dave Methvin, et de discuter de la manière dont il s'est impliqué dans le projet et des perspectives d'avenir pour le développement frontal. Il contribue à jQuery depuis 2006 et est également président de la fondation jQuery..
Le succès de jQuery nous a empêché de changer quoi que ce soit.
J'ai commencé ma carrière en tant que programmeur C à plein temps, travaillant sur des systèmes embarqués tels que la navigation à bord de navires, la robotique, l'automatisation d'usine et les télécommunications. Après cela, je me suis lancé dans le journalisme informatique et j'ai écrit une colonne JavaScript lorsque j'étais chez Windows Magazine. Lorsque WinMag a fermé ses portes, j'ai cofondé une start-up qui a construit un utilitaire système basé sur JavaScript et HTML pour Windows, qui automatisait de manière fondamentale de nombreux conseils donnés dans le magazine..
Quand j'étais au démarrage, je cherchais un meilleur moyen d'organiser le JavaScript et le HTML que nous écrivions. J'ai lu le billet de blog 2005 de John Resig décrivant ce qui allait devenir jQuery. Je lui ai envoyé un email et il m'a répondu qu'il préparait une liste de diffusion pour les personnes intéressées..
Alors tout à coup, il y a ce groupe de gens très talentueux qui discutent de la bibliothèque.
Beaucoup d'entre eux sont toujours avec le projet à ce jour. C'est l'un des talents peu connus de John et l'une des principales raisons du succès rapide de jQuery; il est très inclusif et ouvert à la participation de tous.
J'ai officiellement pris les rênes de jQuery Core en juillet 2011, bien que j'y ai déjà beaucoup travaillé. Quant à pourquoi? Je pense que John recherchait son prochain grand défi, un défi qu'il semble avoir trouvé à la Khan Academy.
Le succès de jQuery nous a compliqué la tâche de changer quoi que ce soit, même s'il s'agit d'un changement positif, tel qu'un correctif ou une amélioration de la cohérence de l'API. Étant donné qu'environ la moitié des sites Internet utilisent jQuery, nous pouvons être pratiquement certains que tout Le changement que nous apportons à la bibliothèque sera un changement décisif pour quelqu'un. Bien que nous pratiquions des bêta, la grande majorité des utilisateurs préfèrent attendre la fin de la version avant d'essayer le nouveau code, ce qui signifie que nous ignorons souvent l'impact d'un changement..
jQuery Core est une bibliothèque pour simplifier le parcours, la manipulation et la récupération de documents HTML..
Lorsque jQuery est arrivé en 2006, les développeurs Web connaissaient les particularités des navigateurs et étaient heureux que jQuery les atteigne à 90% pour la compatibilité entre navigateurs. Beaucoup de développeurs actuels n'ont jamais vécu dans ce monde et sont surpris que jQuery ne puisse pas faire en sorte que chaque petite différence disparaisse d'un navigateur à l'autre. Mais il existe des limites à notre capacité à résoudre les problèmes de navigateur. Les développeurs doivent comprendre cela. Plusieurs fois, la solution utilise un correctif simple au niveau de l'application ou utilise un plugin qui répond à un cas rare spécifique..
Les bogues sont classés par ordre de priorité, qu’il s’agisse d’une régression, de leur impact général sur la communauté, de leur gravité et de la complexité d’un correctif. La plupart des problèmes de non-régression sont des cas extrêmes ou des bogues de navigateur qui se propagent jusqu'à l'API jQuery. Notre défi consiste à les résoudre sans créer une multitude de solutions de contournement complexes dont la plupart des gens n'ont pas besoin et en introduisant d'autres bogues dans le processus..
Puisque jQuery facilite la création d'effets impressionnants en utilisant seulement quelques lignes de code et des plugins tiers, il est inévitable que des non-professionnels tentent de l'utiliser. Parfois, ils réussissent et d'autres fois, ils créent un gros désordre, il faut que quelqu'un vienne nettoyer et nettoyer. Je ne vois pas de solution à ce "problème" autre que de rendre jQuery plus obtus afin que seuls les programmeurs professionnels puissent le résoudre. Ça ne va pas arriver.
Même si vous supprimez IE 6/7/8, il y a BEAUCOUP de code dans jQuery pour lisser les bogues et les incohérences du navigateur. J'étais un peu déprimé de voir combien de ces lignes devaient rester pour jQuery 2.0. Il semble que tous les constructeurs de navigateurs sont trop occupés par la mise en œuvre de nouvelles fonctionnalités brillantes telles que CSS3 pour pouvoir corriger les fonctionnalités de base. Et pourquoi devraient-ils se donner la peine de le réparer, car jQuery le corrige et donc personne ne se plaint de leur?
Les frameworks MV * sont les endroits où se trouvaient les bibliothèques DOM il y a six ou sept ans lorsque jQuery est arrivé sur les lieux. Il y a beaucoup de diversité dans leur approche de la conception, ce qui est une bonne chose. La plupart de ces infrastructures sont heureuses de laisser jQuery s'occuper des problèmes de DOM entre navigateurs afin de pouvoir se concentrer sur les problèmes de conception d'applications de plus haut niveau. Nous sommes définitivement complémentaires à leurs efforts.
J'aime plaisanter en disant que "le noyau n'est pas terminé tant que l'interface utilisateur ne fonctionnera pas".
jQuery Core est une bibliothèque qui simplifie la traversée, la manipulation et la récupération de documents HTML. Parfois, les gens veulent repousser les limites et demander pourquoi nous ne prenons pas en charge les technologies SVG, VML ou autres technologies Webbish, mais c’est à cela que servent les plugins. Nous voulons que l'API de jQuery reste concentrée sur les opérations DOM. Aller au-delà de cela dans la bibliothèque principale ajouterait beaucoup de ballonnement dont peu de gens ont besoin.
jQuery Core peut être utilisé en tant que module nommé par AMD et chargé dynamiquement. En général, les modules nommés sont mal vus, mais de nombreux plugins jQuery s'attendent à partager un objet global jQuery. Je ne suis pas satisfait de l'état actuel du chargement du module JavaScript et je préfère un processus simple combinant et minimisant la plupart des tâches que je réalise. Néanmoins, AMD est suffisamment populaire pour que nous voulions que jQuery Core le prenne en charge afin que les utilisateurs d’AMD puissent charger jQuery à partir d’un CDN, par exemple..
Les solutions de contournement pour IE 6/7/8 représentent plus de dix pour cent de la taille totale de la bibliothèque jQuery 1.9 et ces solutions de contournement ont également une incidence sur les performances. Il existe de nombreux endroits où ces solutions de contournement ne sont tout simplement pas nécessaires, tels que les applications Windows 8, les plug-ins Chrome et Firefox, les applications PhoneGap / Cordova sur une plate-forme mobile spécifique ou les programmes node.js où une bibliothèque telle que Cheerio est utilisée pour charger jQuery..
C’est l’audience principale de jQuery 2.0 pour le moment; la plupart des sites Web Internet devraient continuer à prendre en charge les anciennes versions d'IE en utilisant jQuery 1.9.
Par exemple, je ne vois pas les sites Web Target ou Wal-Mart utiliser jQuery 2.0 pendant au moins quelques années; Les utilisateurs d'IE8 ont aussi de l'argent! Puisque les deux API sont synchronisées, il est possible d'utiliser des commentaires conditionnels pour inclure l'un ou l'autre pour un navigateur spécifique, mais pour être honnête, je ne pense pas que cela en vaille la peine.
Etant donné que jQuery UI et Mobile dépendent de Core, nous les consultons sur les problèmes de feuille de route, le cas échéant. Ces projets exécutent également leurs tests unitaires directement auprès de Github par rapport à notre version la plus récente, de sorte que nous sachions immédiatement si nous avons cassé quelque chose. Néanmoins, j'aime plaisanter en disant que "Core n'est pas terminé tant que l'interface utilisateur ne fonctionnera pas", et nous rencontrons généralement quelques problèmes après chaque publication. QUnit est un peu différent; nous sommes leur client. Nous leur demandons parfois des fonctionnalités et, à l'occasion, leurs mises à jour interrompent nos tests unitaires. Nous avons donc un avant-goût de notre propre médicament.
Nous considérons la conférence jQuery comme un rassemblement pour les développeurs qui créent des sites Web et des applications Web. Une partie de ce qu'ils veulent savoir concerne jQuery, mais nous ne voulons pas en rester là. Tout bon développeur doit élargir ses horizons et continuer à apprendre des outils et des techniques pouvant l’aider à s’améliorer..
Les innovations viennent de toutes les directions. Les guerres de cadres de MV * donneront probablement des approches bien meilleures et plus rapides pour développer des applications et des sites Web; nous verrons certainement une consolidation similaire à celle de jQuery.
La conception adaptative est un autre sujet important et j'espère que les améliorations apportées au CSS et aux images réactives faciliteront sa mise en œuvre au cours de l'année à venir.
Sur ce dernier point, jQuery travaille avec les groupes de normalisation du W3C et de l’ECMA pour garantir que les développeurs Web des tranchées soient représentés lors de la prise de décision..
Accentsconagua