Il n’y a pas besoin de plugin pour ça
Plus je fais mon bonhomme de chemin en tant qu’intégrateur, et plus je me rends compte qu’une différence majeure entre un intégrateur débutant et un intégrateur avec un peu plus de bouteille réside dans la confiance accordée à du code externe. Là où un intégrateur débutant va concevoir un site comme un assemblage de plugins et de bouts de codes trouvés sur le net, un intégrateur expérimenté s’en méfiera comme de la peste, à la limite du syndrome NIH. Plus j’avance et plus je me rends compte que la plupart du temps, il n’y a pas besoin de plugin pour faire quelque chose. Au contraire.
Récemment un collègue est tombé sur une page d’un site client qui déclenchait une action au bout d’une seconde. Il est resté bloqué deux secondes en lisant le code car le code JavaScript utilisait une fonction doTimeout
, et pas la fonction native en JavaScript setTimeout
. Il s’avère que doTimeout est un plugin jQuery dont la baseline est « Comme setTimeout, mais en mieux« . Et par mieux, ça veut surtout dire que ça fait exactement la même chose que la fonction setTimeout
, mais avec une syntaxe proche de jQuery, avec la possibilité de chaîner les fonctions. C’est bien, mais dans 99% des cas ce n’est pas utile, et ça ne l’était certainement pas dans ce cas précis. Et pourtant ça a été appelé sur cette page, avec le Ko et la requête HTTP supplémentaire que ça impose. Ce n’est pas beaucoup 1 Ko. Mais 1 Ko pour écrire en jQuery ce qui aurait pu s’écrire en une ligne de JavaScript, c’est beaucoup.
Ça m’a rappelé mes premières années, quand on parlait de DHTML, de Scriptaculous, de Prototype, mais pas encore de Mootools ou jQuery. J’avais fini l’intégration d’un site. Le chef de projet commence à recetter, et tout de suite m’interpelle.
Le chef de projet : Les sous-menus ne fonctionnent pas.
Moi : Euh… Quels sous-menu ?
Je n’étais pas au courant qu’il devait y avoir des sous-menus. Ça n’avait été spécifié nulle part. Et apparemment, ce n’était pas utile parce que le directeur technique avait dit qu’il y en avait des tout fait très bien. Me voilà donc en urgence en train d’essayer d’installer un sous-menu, avec des compétences en JavaScript alors proches du néant. Je galère, je tâtonne, et puis je finis par avoir quelque chose de fonctionnel. Mais ça n’avait rien de qualitatif (dans la mesure où l’on peut quantifier la qualité d’une intégration). Et surtout j’avais l’impression de n’avoir rien appris. Oui, je savais désormais mettre en place un menu avec cette bibliothèque JavaScript en particulier. Mais ça ne m’aidait pas plus à comprendre le fonctionnement de base de JavaScript et du parcours du DOM.
Un an plus tard, après avoir fait quelques pas supplémentaires en JavaScript, je devais à nouveau intégrer un menu supplémentaire. Et cette fois-ci, j’ai décidé de me lancer, avec mon code HTML et Mootools. Et là j’ai réalisé à quel point la mise en place d’un tel menu était ridiculement facile (en particulier avec un framework de parcours de DOM qui évite du code un peu verbeux). En quelques lignes, j’avais reproduit le fonctionnement que j’avais eu du mal à obtenir un an plus tôt. Et c’était un sentiment enivrant de liberté, un peu comme faire du vélo pour la première fois sans roulettes. Et aussi l’impression d’avoir perdu un temps à courir après le bon plugin ou la bonne bibliothèque qui fait exactement ce qu’on recherche, alors que le faire de zéro demandait autant voire moins de temps pour un enrichissement personnel bien plus grand.
Loin de moi l’idée de vouloir bannir strictement tout code tiers, il est important de réaliser que les problèmes résolus par des plugins n’ont souvent pas grand chose à voir avec les problèmes que vous essayez de résoudre.