Hello,

Merci pour ton retour d’expérience.
Figure toi que je suis aussi d’accord avec certains de tes arguments (tu as vu, je ne suis pas une personne de très difficile, j’aime surtout discuter).

Il ne faut pas voir ma critique des plugins comme une critique des librairies, il m’est récemment arrivé de ne pas avoir le temps de faire certains de mes scripts en full vanilla et j’ai du, au dernier moment, patché avec du jQuery car je n’arrivais pas à dégager du temps pour cela. (j’ai tout de même mis des //TODO ça et là dans mon code pour y revenir plus tard…)

J’aimerai même, pour les intégristes, préparer un article sur jQuery, me faire l’avocat du diable en cette période trouble, parler de belles choses comme les Deferred / Promises que j’ai récemment utilisé pour une petite factory à lazy-loading… une idée d’un script simple, qui ne fait pas le café et qui finalement marchait pas mal du tout (sisi).

Ne vois pas non plus dans mon article un quelconque démonstration d’égo (même si j’ai un égo réputé démesuré) mais plutôt comme un coup de gueule en fin de projet qui se passe mal, qui m’a énervé, m’a fatigué.

Je ne dis pas non plus que je préfère coder un plugin moi-même nécessairement, je remet surtout en question le fait que ces choix sont parfois fait par les mauvaises personnes

Ce que je dénonce, c’est l’utilisation systématique d’usine à gaz de plugins qui propose justement de faire le café, jouer au loto et en plus de populer ton document avec tout plein de fioritures donc tu n’as pas besoin. Je suis pour le « keep it simple » et j’adore l’idée qu’on puisse réaliser pour chaque projet de tout petit script qui font ce qu’ils ont à faire. J’ai récemment eu l’occasion de démontrer cela sur un projet qui utilisait jQuery + requireJS ainsi qu’une floppée de petites factories bien utile, simple à utiliser, simple à debugger, simple à écouter, et qui étaient censé aider mes collègues plus que leur rendre le travail pénible. J’ai surement réinventé la roue mais qu’est-ce que j’ai pu apprendre… quel plaisir de pouvoir partager mes petits scripts avec d’anciens collègues, via mon gist. C’est à ce moment là que j’adore mon métier.

D’ailleurs, c’est bien vers cela que la mode va tendre dans le futur, des petits scripts, qui font le boulot, le « keep it simple » très cher à beaucoup de développeurs.

Alors bien sûr, je ne suis plus comme il y a un an dans l’idée de travailler dans des agences qui doivent régulièrement sortir des sites, je suis à peine rentré dans ce milieu que j’en suis sorti très vite, ce n’était pas ma vision de mon métier, d’où cet article.

Depuis 6 mois je travaille pour un client qui ne rechigne pas à demander du « sur-mesure » et j’en suis heureux. J’ai choisi de tenter l’aventure dans une agence à client quasi unique, pour ne pas avoir à faire la course, je suis pas un sportif vois-tu.

Et ne soit pas trop méchant avec cet ancien collègue qui t’a tout fait debugger, il a voulu s’essayer, il a voulu y arriver et comme beaucoup il s’est cassé le nez sur cette magnifique DOM API OF DOOM. His name is Robert Paulson.

Encore merci pour ton retour, c’est surtout pour cela que j’ai écris mon article !

pourquoi ?
1 – En entreprise on te demande fréquemment un module / plugin php / jquery ou autre délivrant toute une trousse à outils et qui fait le café en même temps et prend les appelles de ton supérieur.
Donc du coup vue la pression exercé sur les développeurs niveau timing c’est très serré. D’où l’utilisation d’un plugin si les fonctionnalités demandé répondent aux besoins.

2 – « vouloir développer son plugin, pour faire mieux »… C’est assez présomptueux je trouve car c’est souvent ce que j’ai pu rencontré dans différente entreprise très varié dans le dev.
Exemple: J’avais un collègue même âge que moi mais par contre qui développait en php et javascript depuis 7 ans en auto didacte. Après une formation en centre il a travaillé chez nous.
Il voulait et préférait tout développer lui même (on sentait son orientation). Résultat ?
Tous, je dis bien tous les modules javascript qu’il avait développé (si on peu appeler ça des modules) étaient bourrés de bugs et j’ai du tout corriger ! En supprimant tout et remplacent par des plugins existant ou bien en développement mes propres plugins.
Il avait plus d’années d’expériences que moi en js et notamment le DOM et function js. Mais son gros problème est qu’il avait du mal à apprendre et se jetter dans un autre code que le sien.
Notamment jquery mobile, il a voulu développer son propre framework mobile, résultat il n’était compatible que sur son écran, il est beau le rosco de la prog.
Tous ça pour dire que j’ai rencontré pas mal de développeur qui se disait bon en js ou autre, qui développaient rapidement. Mais au final, moi qui ne m’estime pas être un cador dans le dev js, je leur ai appris des bonnes pratiques et fonctionnalités du dom assez cruciale qui permettait de rendre leurs code plus compatible avec d’autres js.
Beaucoup de prétention dans la programmation et j’ai peu rencontré de réel bon développeur hormis certains contact sur le web que j’ai à l’étranger ou ancien collègues.

3 – Quand tu dois développer un plugin assez conséquent (et c’est souvent le cas), un plugin partagé sur le web, c’est des centaine voir des milliers de retour de développeur et de situation qui nous parviennent.
Lorsque tu développes pour ta boite, c’est que un retour des tes collègues et clients.

4 – Quand tu développes ton plugin en entreprise on te laisse rarement le temps d’écrire toute la doc de ton plugin (certain demande pas mal de doc bien organisé), alors que utiliser un plugin libre sur le web, aura été éprouvé et tu trouveras la doc pour.

5 – Créer ses propres modules c’est bien car effectivement on apprend dans diverses situations, mais la demande est tel dans la part des employeurs que tous les développeurs n’ont pas forcément le temps d’avoir tester de créer par exemple son propre framework avec des interfaces, des abstracts, router etc…

L’informatique évolue tellement vite que c’est comme si tu demandais à un future scientifique de faire tous ce qu’un vétérant de la science aura fait. Si on réfléchit bien on se rend compte que pour ce future scientifique, si il veut avoir le même niveau qu’un scientifique vétérant il lui faudra autant d’année et qu’il aura le même niveau lorsqu’il aura son âge.
Si tout le monde faisait comme ça, même en informatique, on réinventerait la roue dans bien des domaines.

La où je te suis, c’est que beaucoup d’entreprises utilisent des plugins de façon pro sans payer alors qu’ils ont les tunes, eux faut pas les voler, par contre eux peuvent nous voler.

Donc en fait chaque développeur n’a pas vraiment le choix, mais doit s’autoformer à côté sur des problématiques qu’il n’a pas connu et dont il n’a pas le besoin présent forcément dans son entreprise. J’ai commencé à développer mon propre plugin jquery datagrid, c’est très péchus et il vaut mieux bien connaître le dom et l’api javascript comme jquery.

jQuery est ce que javascript aurait du être, aujourd’hui les besoins technologique en javascript sont tels que l’on ne peut plus développer un grosse appli RIA en pure js, à moins de s’être créé son propre framework, ce qui reviendrait au même que si l’on utiliser un framework déjà existant et plus éprouvé.

Car au final, vous pouvez développer votre propre framework js, php ou cms, selon votre niveau dans un domaine vous pouvez faire mieux mais dans un autre vous rencontrerez certainement les mêmes problématiques que d’ancien développeur ont rencontré.

Ne t’inquiète pas, dans quelques années tu auras pleins pleins de choses à dire sur les mauvaises pratiques… le front, c’est une usine à « gueulard » :)

Si tu veux juste faire de la sélection, prend Sizzle tout court puisqu’il fait partie de jQuery.

Même si je sais qu’au final on pensera toujours que l’agence d’à côté ne sera pas si scrupuleuse :(

Et pour ton dernier argument, on parle de plugins, pas de librairies entières, je peux comprendre qu’une équipe n’ait pas le temps de coder un éditeur WYSIWYG ou bien, disons, un moteur de template.

Pour le cas du design, cf. au dessus, on est parfaitement d’accord. Je préfère me décarcasser à tous coder à la main dans la mesure ou le projet me le permet et dans les cas de « nouveautés » faut le signaler clairement au demandeur que ça prendra du temps à coder et que non je fais pas 2000 lignes de code en 5 minutes. Mais la aussi dans la réalité professionnel on joue avec des forces antagonistes.