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.

  1. Pauland, le

    C’est exactement la même histoire pour les devs.
    Quand je dois utiliser un composant ou une lib externe, c’est après avoir fait quelques essais  » à la mano », afin d’être sûr de ne pas pouvoir m’en passer.

  2. Virtuousquare, le

    jQuery Tools, c’était le bon vieux temps ! …Enfin, surtout le vieux temps…
    Personnellement la principale raison de ne pas utiliser de plugin, c’est surtout (et je te cite) un « sentiment enivrant de liberté » et une grande satisfaction.
    Mais à l’inverse, j’associe parfois ça à un de mes défauts de production, je refais régulièrement les mêmes scripts, car je ne les ‘générise’ pas toujours. J’ose espérer que je m’améliore à chaque fois que je les reproduis (en temps et en qualité), mais c’est quand même une petite perte de temps.
    Donc, les plugins tiers a utiliser avec parcimonie et leur préférer les plugins-maison.

  3. Mathias S., le

    Même problématique dans le monde de WordPress, au début je mettais des plugins pour résoudre des problèmes ou augmenter les fonctionnalités, puis je suis devenu de plus en plus sélectif, pour des problèmes de loading, compatibilité, sécurité principalement.

    Maintenant, quand je créé un site sous WP ou quand je conseille sur des boites utilisant un thème premium custom (à base de child theme donc) je leur donne uniquement les meilleurs plugins (comme les fameux plugs de Lester Chan) et 4-5 maximum. C’est bien plus fluide, plus secure, plus propre.

    Tout ça pour dire que malgré la mise en avant des plugins, quelques soit le domaine (CMS ou intégration comme toi) rien ne vaut du fait maison !

  4. Stéphanie, le

    Je suis une quiche en JS (à vrai dire je n’ai jamais vraiment eut le temps d’apprendre correctement), du coup je comprends assez bien ton ressenti quand tu dis « Et c’était un sentiment enivrant de liberté, un peu comme faire du vélo pour la première fois sans roulettes. ». J’ai un peu le même quand j’arrive à écrire toute seul des petits snippets de code JS (ou jQuery) qui fonctionnent.

  5. Simon Tripnaux, le

    Il y a même certains cas, très nombreux, où il n’y a pas besoin d’un script aussi lourd que WP pour aligner quatre malheureuses pages qui ne seront jamais mises à jour … quand par dessus ça il y a une grosse couche de plugins à la noix plein de liens obfusqués et autres joyeusetés … bref : vive Notepad++ ! ;)

  6. Sébastien Decamme, le

    En fait, on peut même se demander si l’utilisation de jQuery est nécessaire. Dans la majorité des cas, il ne sert qu’à faire tourner un couroussel. Et il pèse combien jQuery déjà ? Ha oui, plus de 80ko…

  7. MoOx, le

    C’est là qu’on soulève un problème. Un « intégrateur » devrait-il gérer ce qu’un « développeur » devrait faire (ou mettre en place). Je ne pense pas.
    Il faudrait peut être mieux payer une formation « les bases de JavaScripts » pour être capable de coder un menu soit même, ça couterait aussi chère qu’une ou 2 installations de plugin.

    J’ai même envie de dire (attention je ne veux blesser personne, ceci est un encouragement), mesdames, messieurs, devenez développeur front-end !
    J’ai choisi cette voie, et maintenant j’utilise http://vanilla-js.com/ c’est vraiment top !

    « Donne un poisson à un homme, tu le nourris pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours. »

  8. Mathias S., le

    @Simon: ça me rappelle encore une fois cet article que je trouve vraiment bon:

    http://konigi.com/notebook/static-html-new-old-school

  9. Marc ARAKELIAN, le

    Toujours cette même problématique du « préfabriqué ». Ce n’est pas le fait main soit mieux « dans tous les cas », ça dépend évidemment de qui le fait et pour quelle destination, mais quand même…

    Ca me rappelle le temps – lointain maintenant – où j’utilisais Dreamweaver pour faire ce qu’on me demandait, et où je constatais avec effarement qu’il générait littéralement des dizaines de lignes pour une fonction (javascript aussi) qui m’en prenait 3 ! Et quand il faut reprendre ce code par la suite pour le personnaliser… bonjour l’angoisse !

    Pour les plugins (le cas des bibliothèques c’est encore autre chose) que ce soit sous WP, Joomla ou autre, c’est pire : il faut en essayer des dizaines pour en avoir un qui semble fonctionner correctement… avec cette version – très provisoire – du CMS. Et s’il lui manque quelque chose on peste : « zut, ça je le sais le faire, grrr » mais on ne va pas forcément bidouiller le code d’un greffon qui va être mis à jour dans 2 mois ! Encore moins le coeur de WP, sinon maintenir de nombreux sites devient un enfer.
    Seuls les child-themes sont pratiques pour ça.

  10. A.nonym, le

    A mon sens il y a une distinction importante à faire entre les plugins « support de code », par exemple les polyfills ou les fonctions pratiques (modernizr, greensock si y’a de la grosse animation, etc) et les plugins « fonction du site », par exemple les Carrousels, diaporamas, et autres conneries.

    J’utilise assez volontiers (et même très volontiers) les premiers lorsque c’est pertinent, je ne peux pas sentir les seconds (à de rares exceptions, genre quand c’est très très bon. Isotope par exemple.)

    Après y’a des fonctions que je me retrouve à copier/coller d’un site un l’autre (ma fonction de validation d’un formulaire), au final et à terme ça revient au même qu’un plugin…

    JQuery, c’est un autre débat. C’est ridicule de l’inclure pour cent lignes de JavaScript, mais d’expérience il devient assez vite rentable niveau gain de temps/poids de page.

    La règle la plus saine à mon sens, c’est « si tu comprends pas le code source, t’utilises pas. »

  11. Torinski, le

    Le problème récurrent avec Jquery (et autres grandes bibliothèques) c’est que le javascript n’étant pas enseigné (et ne parlons pas des développeurs habitués à la programmation objet par classe et qui découvre le prototypage), les gens finissent par ne savoir faire que du jquery ! c’est très bien si le plugin/ bout de code trouvé fonctionnement exactement comme ils le souhaitent. sinon c’est la catastrophe..

    Dans une grande majorité de cas, Jquery (hors plugin) n’est finalement utilisé que pour quelques fonctions, et sélecteurs (charger Jquery pour faire une fois un getElementById n’est pas une bonne chose).

    Je pense que savoir un minimum de JS est une bonne chose pour un intégrateur (ne serait ce que savoir comment marche le DOM, savoir mettre en cache des sélecteurs, etc)

  12. A.nonym, le

    La parenté lointaine entre le JS et JQuery est un vieux débat… c’est aussi l’un des fondements du succès de JQuery dont la syntaxe est plus logique (chain) et proche du CSS (selecteur, au point que le js a piqué le principe.)

    C’est moins un problème qu’on ne le dit : un intégrateur peut être tout à fait compétent et pondre du code tout à fait correct sans connaissance du JavaScript. La mise en cache des selecteurs n’est par exemple nullement l’apanage du vanilla.

    Attention, je parle d’un intégrateur web bossant sur des sites « classiques », mais des applications ou du « Adobe HTML5 player ». Des besoins relativement simples ne demandant pas de recourir aux prototypes, etc.

    Alors bien sûr à terme cet intégrateur aurait intérêt à se mettre au JavaScript, pour améliorer sa compréhension du web et comprendre comment JQuery fonctionne, mais ce n’est pas une nécessité.

    La JQuery tax existe, mais franchement y’a cent trucs à optimiser avant de dégager JQuery pour tout réécrire en vanilla.

  13. torinski, le

    ha mais je ne dis pas qu’il faut tout ré-écrire en JS (ou que cacher les sélecteurs est l’apanage du JS) mais que j’ai trop souvent vu mettre des biblio comme Jquery pour au final 12 lignes de JS basique. Je dis que malheureusement dans les exemples que je vois tous les jours, les intégrateurs manquent de connaissances en JS (ou plutôt sur la partie DOM du js et des navigateurs) pour justement penser à cacher leurs sélecteurs (même en utilisant Jquery).
    je n’ai rien contre Jquery (qui a d’énormes qualités) mais je milite pour qu’on apprenne tout de même un minimum ce qui se passe derrière.

  14. torinski, le

    D’ailleurs pour ce que j’en vois les intégrateurs en général sont souvent preneurs de formation en JS (et ce même après avoir utilisé jquery pendant un moment)