# Pourquoi discutons-nous même de l’avenir de jQuery?

Ne manquez pas la vidéo au-dessus de l’article !

Parce que jQuery exécute toujours la majorité de la logique web frontend! Il alimente environ 70% des meilleures pages Web et 20% de l’ensemble du Web (Source). C’est énorme !

Mais cela rend la question concernant son avenir encore plus étrange.

jQuery a des problèmes. C’est partout et ce n’est pas vraiment à l’épreuve du temps. C’était un outil incroyable lorsqu’il a été publié en 2006, mais les problèmes de base qu’il corrigeait à l’époque ne sont plus des problèmes. Au lieu de cela, vous pouvez maintenant rencontrer beaucoup plus de problèmes lors de l’utilisation de jQuery.

Pour comprendre cela, considérons les problèmes que jQuery a résolus en 2006.

JavaScript était un peu cassé et les navigateurs l’implémentaient très différemment

C’était l’une des principales choses avec lesquelles jQuery a aidé. Tout à coup, vous aviez une API facile à utiliser qui vous permettait de manipuler le DOM. Et encore mieux que cela : La même API fonctionnait sur tous les principaux navigateurs !

$('h1').text('Awesome!')

JavaScript et le web dans son ensemble étaient beaucoup moins matures

jQuery permettait aux développeurs de simplement « faire plus » sur le web – sur le frontend pour être précis. La création d’interfaces utilisateur attrayantes (pour lesquelles vous avez besoin de JavaScript) était plus facile car vous pouviez utiliser une API bien documentée. Animer des éléments, ajouter et supprimer du contenu, changer de style et réorganiser les éléments était beaucoup plus facile à réaliser qu’avec JavaScript vanilla. jQuery a également ajouté une API Ajax puissante et pourtant accessible qui a également facilité l’envoi de requêtes en arrière-plan. Il s’agit d’un bloc de construction essentiel des interfaces utilisateur pilotées par JavaScript, car vous n’avez pas à charger une nouvelle page à chaque action de l’utilisateur et vous pouvez charger ou manipuler des données côté serveur en coulisses.

    Apprendre Vue.js

    Vue.js rend la création de pages Web réactives simple. Une belle syntaxe + des fonctionnalités puissantes – ce n’est pas le pire package que vous puissiez obtenir.

    Apprendre React

    React est une excellente alternative à Vue.js. Il est extrêmement populaire et vous ne devriez absolument pas le manquer!

    Apprendre Angular

    Angular a tout commencé! Apprenez le cadre qui est la mère de React.js et Vue !

# Qu’est-ce qui a changé ?

Les problèmes résolus par jQuery ne sont plus des problèmes.

JavaScript a mûri, la compatibilité du navigateur s’est améliorée. Nous avons un écosystème de développement frontend dynamique avec des milliers de paquets et d’outils, nous pouvons utiliser des bibliothèques Ajax beaucoup plus puissantes comme Axios si nous le voulons.

Cela ne signifie pas que tout va bien mais les problèmes de base qui ont été résolus par jQuery n’existent plus vraiment.

Au lieu de cela, jQuery now est un outil qui est souvent (pas toujours bien sûr) utilisé par des développeurs Web moins expérimentés qui n’ont jamais basculé vers JavaScript vanillé ou des frameworks comme Angular ou React.

Et c’est important à comprendre au fait: Nous ne parlons pas seulement de jQuery vs Angular. Vanilla JavaScript est une véritable alternative !

Alors que la traversée et la manipulation des DOM étaient beaucoup plus difficiles en 2006, nous avons maintenant de nombreuses fonctionnalités comme querySelector intégrées à vanilla JavaScript. Ces choses fonctionnent et fonctionnent même sur tous les navigateurs.

Si vous avez la possibilité d’utiliser JavaScript vanilla au lieu d’obtenir fondamentalement la même chose avec jQuery, il est évidemment préférable d’utiliser l’option vanilla. Vous enregistrez le téléchargement du package supplémentaire et vous n’avez pas à apprendre une syntaxe supplémentaire.

# Ce n’est pas seulement du JavaScript Vanille

Ce n’est pas seulement du JavaScript vanille cependant. Nous avons simplement de meilleures alternatives ces jours-ci.

Le JavaScript Vanillé a clairement encore ses limites. Si vous construisez une interface utilisateur complexe avec beaucoup de logique implémentée via JavaScript, vous vous retrouvez rapidement dans des situations où vous devez essentiellement écrire une sorte de code spaghetti. La gestion de l’état DOM est difficile après tout.

Et pas seulement ça. Vous rencontrez régulièrement des situations où votre logique de traversée DOM se casse si jamais vous décidez de réorganiser votre code HTML (ou d’introduire de nouveaux éléments).

<div> <h1>What's new?</h1> <div> <p>An interesting discussion over the future of jQuery evolved over the last days.</p> </div></div>
$('#news') .find('div') .find('p') .text('This replaces the paragraph text - hopefully')

Ce code cessera de fonctionner si vous modifiez le code HTML comme ceci.

<div> <h1>What's new?</h1> <p>An interesting discussion over the future of jQuery evolved over the last days.</p></div>

Et la même chose serait vraie pour les techniques de traversée JavaScript vanilla.

Évidemment, vous pouvez écrire du code qui fonctionnerait toujours dans le scénario ci-dessus. Mais il pourrait alors se briser dans des circonstances différentes. Ou vous vous retrouvez avec une chaîne assez longue de méthodes de traversée pour sélectionner en toute sécurité tout ce que vous prévoyez de manipuler. Et cela ne devient plus difficile que si vous créez ou supprimez manuellement des éléments DOM via jQuery.

Si vous avez déjà eu un cas d’utilisation où vous deviez ajouter et supprimer des éléments dynamiquement – disons en fonction d’un tableau JavaScript contenant des données – vous connaissez la douleur associée à cela lorsque vous utilisez jQuery ou vanilla JavaScript. Laissez-le tranquille si vous souhaitez ensuite travailler avec ces éléments (par exemple, joindre des écouteurs de clic ou des styles).

#Cadres à la rescousse !

Il y a une solution pour ça!

Des frameworks JavaScript comme Angular, React (oh, c’est une bibliothèque en fait – pardonnez-moi les gens de React) ou Vue par exemple.

Tous ces frameworks ont une différence fondamentale par rapport à jQuery (et au JavaScript vanillé): Vous n’écrivez pas de code pour naviguer manuellement dans le DOM.

Vous utilisez plutôt une approche déclarative.

Qu’est-ce que cela signifie?

Eh bien, voici comment vous pouvez sélectionner et manipuler en toute sécurité le contenu HTML du début de cet article – cette fois en utilisant Vue:

<div> <h1>What's new?</h1> <div> <p>{{ myText }}</p> </div></div>
new Vue({ el: '#news', data: { myText: 'This never fails to hit its target', },})

Comme vous pouvez le voir, Vue suit clairement une philosophie différente de celle de jQuery. La même chose serait vraie pour React et Angular d’ailleurs.

Pour le reste de cet article, j’utiliserai Vue pour les exemples – tout simplement parce qu’il a une très belle syntaxe et qu’il est facile de commencer avec. Importez Vue dans votre page Web et vous êtes prêt à partir.

Mais Angular et React suivent également des approches comparables. Si vous voulez en savoir plus à ce sujet, j’ai des ressources utiles pour vous:

  • Angular – Le Guide complet
  • React – Le Guide complet
  • Angular vs React vs Vue

Et bien sûr, au cas où vous voudriez plonger plus profondément dans Vue, j’ai aussi des ressources à ce sujet: Vue – Le Guide complet.

Ils se concentrent tous sur la possibilité de marquer simplement des endroits dans le DOM où le contenu doit être affiché. Vous n’avez pas à décrire le chemin vers cet endroit – le cadre le comprendra pour vous!

# Mais la solution Vue est plus longue !

Si vous comparez la solution jQuery à la solution Vue, vous voyez clairement que l’approche Vue est un peu plus longue (en termes de lignes de code écrites).

Mais c’était un exemple très simple! Des exemples plus complexes prennent rapidement de la taille et, pire encore, de la complexité en ce qui concerne le code jQuery requis. Mais pas pour Vue (ou les autres frameworks).

C’est parce que l’approche générale est si différente. Si vous décrivez simplement votre structure de données, votre logique et la façon dont vous connectez vos données au DOM (votre modèle pour ainsi dire), vous n’avez pas à écrire autant de code supplémentaire lorsque votre code HTML ou votre logique métier devient plus complexe.

Pour jQuery, c’est une chose différente cependant. Si vous devez atteindre des éléments profondément imbriqués ou si vous devez faire des choses complexes comme parcourir des éléments à créer, vous vous retrouvez rapidement avec le code le plus complexe (et également sujet aux erreurs) que vous avez vu plus tôt.

Cela donnera:

<div> <div>Apples</div> <div>Bananas</div> <div>Milk</div></div>

Les éléments imbriqués <div> sont cliquables et la classe CSS highlighted sera ajoutée à n’importe quel élément en cliquant.

Considérez l’extrait de code Vue (et HTML) qui obtiendrait la même chose:

new Vue({ el: '#output', data: { shoppingList: , },})

C’est toujours une ligne de codes dont vous avez besoin ici, mais c’est tellement plus facile à comprendre, à maintenir et à modifier! Vous déclarez à quoi devrait ressembler votre code HTML à la fin, vous décrivez vos données et gérez votre état selected dans votre code JS.

La magie se produit à l’aide de soi-disant directives – v-for (pour la boucle), v-on (pour l’écoute d’événements) et v-bind (pour changer l’élément HTML) font tout le travail ici. React et Angular ont généralement des solutions comparables, bien que React n’utilise pas de directives. Cela ne vous obligera toujours pas à écrire manuellement tout le code pour sélectionner et créer des éléments.

À mesure que votre application Web (frontend) se développe et que vous construisez des interfaces utilisateur encore plus complexes, vous adorerez une telle approche déclarative qui ne vous oblige pas à des chaînes infinies et non maintenables d’appels css()$(...) et appendTo().

# jQuery est-il au moins plus petit ?

Vue offre une syntaxe nettement différente – elle fait beaucoup de travail en ce qui concerne l’accès au DOM et la manipulation pour vous.

Cela a clairement un prix, n’est-ce pas? jQuery est certainement plus petit, non?

Eh bien no non. Ce n’est pas le cas.

En mars 2018, jQuery pèse 29 Ko minifiés et gzippés alors que Vue est de 30 Ko minifiés et gzippés.Qu’en est-il de React et Angular?

React se compose en fait de deux paquets : ReactDOM et React lui-même. Combiné, vous devez télécharger environ 34 Ko minifiés + gzippés pour le faire fonctionner.

Angular est bien plus grand que cela car Angular est un framework beaucoup plus grand qui convient particulièrement aux grandes applications d’entreprise. Pour de tels types d’applications, il gagnera contre jQuery non pas à cause de la taille de son paquet, mais à cause de toute la douleur qu’il vous sauve.

# Alorsnever n’utilisez plus jamais jQuery ?

La question maintenant est bien sûr de savoir si vous devez toujours utiliser Vue, Angular ou React alors. Ou existe-t-il des cas d’utilisation où l’utilisation de jQuery a toujours du sens?

En général, je crois que le temps de jQuery touche à sa fin. Au moins dans sa forme actuelle.

Vous pouvez toujours le choisir pour des cas triviaux, mais pourquoi n’utiliseriez-vous pas simplement JavaScript vanilla pour cela et enregistrez les 30 ko supplémentaires + la syntaxe supplémentaire dans laquelle vous devez entrer? Vous serez un meilleur développeur Web si vous connaissez vanilla JS de toute façon.

jQuery voit évidemment encore beaucoup d’utilisation dans de nombreuses applications Web héritées et il va y rester pendant un certain temps.

Si vous avez besoin de travailler sur de telles applications Web, vous ne trouverez probablement pas de moyen de contourner jQuery pour l’instant et l’apprendre pourrait donc toujours valoir votre temps.

Beaucoup de paquets tiers populaires reposent également sur jQuery-Bootstrap, le framework CSS, par exemple (malheureusement, il le fait même dans sa dernière version – 4.x). Avoir à ajouter la dépendance supplémentaire à cause d’un tel paquet est ennuyeux, j’essaie donc personnellement de toujours savoir ce que fait exactement jQuery pour ce paquet donné. Une fois que vous avez obtenu cette information, vous pouvez reconstruire la fonctionnalité avec vanilla JS ou un autre framework et réussir à vous débarrasser de jQuery par la suite.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.