Encore un article ou tu es dans le juste :)

Selon moi les plugins c’est bien mais pas de manière systématique et UNIQUEMENT si on sait comment il fonctionne et ses répercutions sur le projet (et donc les répercutions face aux contraintes imposés par le sus-dits projet).

A titre d’exemple pour moi jQuery UI ou jQuery Tmpl (pour les templates) sont des très bons plugins car ils sont pensés pour rentrer dans un certain nombre de cas de gros projets mais quel est l’intérêt pour des sites vitrines ou de petits sites ? Aucun, si ce n’est gagner du temps au détriment de la qualité et de l’image que l’on veut donner au futur d’Internet.
Pour moi une Entreprise qui demande des gars qui savent faire du jQuery devrait systématiquement demander aux gars de connaître les bases pour au moins avoir des notions sur le DOM, la manière dont travail le javascript basique et notamment sur la portée des variables (sur ce point, je vois régulièrement des désastres). Car savoir faire du jQuery c’est bien mais si on fait sans connaître les fondements, non seulement on risque de faire des bêtises mais en plus on risque de ne pas pouvoir utiliser des solutions « légères » et adaptés, ce qui est particulièrement d’actualité avec le tous « mobile ».

Bref, vu que ce n’est pas mon blog et que je ne tiens pas à écrire un roman, je conclus simplement sur le faite que les intégrateurs nous avons une vrai responsabilité pour ne pas avoir le réflexe « plugin ».

Le 07 Nov. 2012 à 14h29 par Yves Astier

Superbe article. Je ne suis pas développeur web mais directeur d’infrastructure au canada et je vie exactement les mêmes enjeux. Les entreprises nous pousses à aller vite, à faible coûts, sans considérer l’impact de support et d’évolution. Il faut livrer!
Au sujet des plug-in, mon petit site web (c’est mon hobby pour me changer les idées le soir) en wordpress regorge de c’est petites saletés, très simple à mettre en place, plutôt complexe à faire cohabiter entre eux, alourdissant l’utilisation de ressources serveurs et de traitement du navigateur. Mais bon, c’est le prix à payer pour moi qui ne souhaite pas faire de code et qui désir avoir un site potentiellement attractif.

Ma plus grande frustration vient de la non évolution de ces plugin. Même ceux que j’achète ont une durée de vie limités. À chaque évolution de WordPress ou du template que j’utilise, j’ai toujours peur de m’embarquer pour plusieurs jours de correction. C’est ce que l’on appel évoluer. mouai…

Au final, ton commentaire au sujet du look des templates est absolument exact. Un petit caroussel en haut, un sidebar à droite, etc. Tous les sites ont la même gueule. C’est navrant. Même chez les producteurs de templates payant (j’utilise ceux de wootheme) on est excessivement redondant. Ils ont beau en produire régulièrement de nouveaux, ils sont aux final tous pareille.

À quand un retour à la diversité?

Le 07 Nov. 2012 à 15h51 par Yannick

Trop de plugin tue le plugin, ça c’est un fait. Surtout quand ces derniers ne sont pas maintenus correctement en prime et ont des implications problématiques sur certains projets.

Ceci dit, certains plugins sont plutôt biens faits, et quoi qu’on en dise, ça permet de gagner du temps. Sur du one-shot pour des petits sites vitrines à petit budget (en gros, je dois travailler vite et bien), je vois pas pourquoi je n’utiliserai pas un JQuery Cycle qui répond parfaitement à ce dont j’ai besoin. Enfin, ça revient à utiliser quelque chose en pleine connaissance de cause.

Après, il y a un autre cas, c’est le pire cas que j’ai rencontré : le client qui bidouille un peu et qui vous impose un script/effet (oui ça existe). Et encore pire quand ce sont plusieurs scripts qui font ramer le site ou qui font plonger la maintenabilité du site vers les abysses. ^^

Le 07 Nov. 2012 à 17h34 par Nico

Concernant Stackoverflow, les réponses « jQuery everything » étaient légions mais c’est devenu me semble-t-il un meme http://meta.stackoverflow.com/a/19492/147697 (voir la capture d’écran, les scores des différentes réponses et le pseudo). Le pourrissage de question avec ce genre de réponse risque de coûter cher en réputation…

Concernant jQuery et les plugins, en lisant « vrai travail responsable », « le chef de projet technique ne s’en préoccupe pas », etc j’imagine que le problème de fond c’est le copier-coller bête façon « je prend un truc sur l’étagère parce que l’auteur est connu ou la couverture est jolie et basta ».
Plugins et jQuery ne sont que des symptômes de la facilité intellectuelle dans laquelle sombrent ces professionnels.
On peut étendre aux symptômes WordPress, ses extensions à la qualité inégale, son écosystème de thèmes ou encore aux préprocesseurs CSS quand on ne se préoccupe pas du code CSS qu’ils produisent.
Je cumule pas mal (je n’utilise quasiment que jQuery et WordPress qui répondent aux besoins simples que j’ai) mais avec mes propres thèmes, extensions choisies et en petit nombre, et copier-coller de mes propres snippets ou fonctions (je ne vais pas recoder un menu déroulant accessible au clavier à chaque projet qui en a besoin, mes collègues ont depuis longtemps amélioré celui-ci). Il y a différentes manières d’utiliser un même outil (quand il est bon au départ) ;)

Le 07 Nov. 2012 à 21h18 par Felipe

@Felipe : « Plugins et jQuery ne sont que des symptômes de la facilité intellectuelle dans laquelle sombrent ces professionnels. » Dans ce cas pour moi ce n’est pas des professionnels mais des amateurs avertis et ils n’ont rien à faire dans des vrais environnement professionnels car ce n’est pas comme ca qu’Internet évoluera proprement.

@Guillaume Richard : « hmm justement, je pense que pour les gros projets il faut limiter les plugins, voir carrément virer jQuery mais pour un petit site vitrine je comprend qu’on ne veuille pas se prendre trop la tête…  » Au contraire je pense que souvent (attention je ne dis pas que c’est systématique car chaque projet doit être réfléchis) les gros projets peuvent bénéficier de choses un peu plus lourde dans la mesure ou le cache est la pour jouer le rôle de « porteur » et permettre du coup d’alléger considérablement si on fait un prorata aux nombres de pages minimum vu par un utilisateur.
Après on est d’accord que « ne pas se prendre la tête » c’est bien mais ce qui fera la différence pour moi entre un site fonctionnel et un site « top » c’est un gars qui aura fait l’effort de sortir strictement le code nécessaire quitte à se prendre la tête mais rendre le site très léger à charger/afficher. C’est d’autant plus vrai avec la mode actuel du « tout un site en une page ».

Pour Stackoverflow, je pense que les deux types de réponses sont convenables, ainsi l’amateur averti y trouvera son compte et le professionnel pourra creuser.

Le 08 Nov. 2012 à 09h16 par Yves Astier

Sur des gros projets j’essaye toujours de me passer des plugins et des dépendances qu’ils impliquent. Par exemple il n’y a rien de plus simple, performant (et gratifiant) que de faire soi-même un carrousel en javascript de bas niveau (getElementById, mon ami), avec touch events, animation CSS, etc grâce aux multiples sources d’inspirations qui existent. Idem pour un menu déroulant, une fenêtre modale, un scrollTop, bref tout ce genre de petites fonctionnalités toutes bêtes. Franchement ce n’est pas si compliqué de convaincre un chef de projet que son équipe est à même de travailler comme de vrais programmeurs et que les outils seront dédiés, adaptés et solides. Le temps de développement n’est pas si long que ça et les délais peuvent le prendre en compte si le projet est correctement planifié.

Ce n’est pas tant une question de réinventer la roue, que de maîtriser de bout en bout ses ressources. On pourra ensuite les réutiliser dans d’autres projets et les y adapter sans effort et même en améliorer les performances ou la technique selon les nouveautés que la veille peut apporter, sans oublier leur optimisation toujours plus poussées inspirée des bonnes pratiques glanées sur le web.

Bon, par contre en cas de grosse charrette ou pour intégrer un éditeur de texte wysiwyg, là je dis merci aux plugins oui.

Le 08 Nov. 2012 à 11h10 par iManu

@Guillaume Richard : j’ai jamais dis le contraire et on est d’accord que la lourdeur inclus pas que le poids mais le gc, le temps de rendu, ect… d’où le fait que je précise bien que ça dépend du projet. Donc dans ton propos on est d’accord sur le fond, seul la façon de le présenter diffère.
Perso je suis très adepte du « on casse pour refaire » adapté à chaque projet, malheureusement dés fois ça ne colle pas avec les contraintes temps et du coup tu te retrouves à expliquer au demandeur que « oui c’est buggé mais oui on vous avez prévenu et donc oui on peut corriger maintenant mais si vous nous filez du budget temps ». Comme toujours la partie compliqué du boulot ou tu dois concilier des éléments qui par nature s’opposent.

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.

Le 08 Nov. 2012 à 12h37 par Yves Astier

J’utilise l’API Dom pour les trucs bas niveaux, très gros, si jQuery serait trop gros mais non, ce n’est pas « intéressant ». Pour mes scripts greasemonkey etc, j’ai le droit à querySelector(All), génial ! Sauf que c’est pas le cas partout et que je peux pas l’utiliser sur mes sites sous peine de me fermer à trop de monde.
Je n’utilise pas de plugins, sauf jQ UI (bien trop lourd mais aussi trop pratique) parce que c’est à mon sens jamais assez flexible, jamais comme je veux, et jamais maintenu (sauf rares exceptions).
S’embrouiller avec l’API DOM n’est pas intéressant, des lignes et des lignes pour récupérer un simple élément et lui faire faire un truc c’est lourd. L’exception c’est avec un langage plus haut niveau (coffee / coco / livescript, par exemple) qui me débarrasse de cette répétition insupportable et improductive.

Le 08 Nov. 2012 à 19h18 par N-D

ça m’arrive de le faire et j’en suis très content, c’est super bien fait et bien découplé. Je n’utilise jQuery que si j’ai beaucoup d’ajax et d’autres trucs.
Comme dit, avec des langages qui se compilent en JS, on regagne la productivité et on ne sacrifie pas les perfs :). Il faut simplement accepter la syntaxe de certains

Le 08 Nov. 2012 à 20h09 par N-D

je suis un peu novice dans le métier mais très bon recul sur la pratique et critiques faites dans un très bon style.

Le 08 Nov. 2012 à 22h27 par dan

Je ne suis pas d’accord avec ton opinion accentué « je préfère coder moi même un plugin ».

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é.

Le 26 Avr. 2013 à 03h30 par shadoo