Le poids de JQuery

(reprise du message précédent)

Artemus24 a écrit :
vous avez tendance à tout développer en Jquery alors que l'on a souvent l'équivalent en Javascript.

Je ne sais pas à qui tu t’adresses, car je ne peux pas dire que je développe tout à l’aide de JQuery. C’est du cas par cas, selon le projet, les scripts à développer ou à intégrer et si j'ai l'intention de faire évoluer le projet dans l'avenir. Il n’est pas rare qu’un client commande des modules supplémentaires dans son site. Si JQuery est déjà en place pour d’autres fonctionnalités, ça simplifie les choses.

Artemus24 a écrit :

Se pourrait-il que vous ayez une méconnaissance du Javascript ?

Pour utiliser JQuery adéquatement et ne pas faire n’importe quoi, il faut quand même connaître un mininum le Javascript.

Artemus24 a écrit :

Il est vrai, qu'il y a encore quelques années le Javascript avait été délaissé, et beaucoup de professionnels ne connaissent pas ou très peu ce langage. La nouveauté faisant, tout le monde est passé au Jquery sans connaitre le Javascript.

Même si je suis d'accord que le Javascript est utilisé très fréquemment maintenant, je n’ai pourtant pas le souvenir qu'il avait été délaissé. Je me souviens encore du DHTML ou des sites qui proposaient une panoplie de script prêt à l’emploi, mais au combien mal écrit et sans aucun standard entre eux. D’ailleurs, je les évitais comme la peste.

Artemus24 a écrit :

beaucoup de professionnels aiment l'usage du copier/coller afin de gagner du temps.
Ils utilisent un Plugins en Jquery dont la totalité (Plugins + Framework) est souvent assez volumineuse. Alors qu'en fait, ils utilisent une seule fonctionnalité de ce qui est proposé.
D'où ma réaction en ce qui concerne ce gaspillage d'espace.

Je comprend ce que tu veux dire. Par contre, je n’utiliserais pas le terme copier/coller, mais plutôt de réutilisation de code existant de qualité, stable et flexible. Ce n’est pas par paresse ou incompétence. C’est avant tout parce qu’en utilisant un script populaire existant, comme certains plugins pour JQuery, cela nous assure qu’il fonctionnera bien. Comme beaucoup de personnes les utilisent, les auteurs reçoivent beaucoup de commentaires et suggestions pour apporter des améliorations et des corrections. Sans compter leur flexibilité qui facilite beaucoup la personnalisation et l’intégration dans différents projets. Il faut aussi se servir de son gros bon sens et ne pas utiliser une bibliothèque pour deux lignes de code.

Artemus24 a écrit :
Je constate que si l'on peut se passer de 30Ko pourquoi ne pas le faire ?

Je poserais la question inverse. Pour profiter de tous les avantages de la bibliothèque, pourquoi ne pas accepter un 30 Ko supplémentaire qui je le rappelle, ne représente que 30% d’une simple photo? Sachant qu’il n’est pas rare de retrouver des images, photos, animations et vidéos sur un site, 30 Ko est négligeable sachant qu’en plus, le fichier se met en cache. Je t’invite aussi à t’informer sur les CDN et leurs avantages.

Artemus24 a écrit :

dois-je comprendre, selon ma troisième remarque, que vous ne développez presque rien et qu'en grande partie, vous faites du copier/coller. C'est un second problème que je dénonce aussi.

Peux-importe la volumétrie, ce qui compte, c'est de respecter le cahier des charges et les délais. Vous préférez optimiser le temps (car le temps c'est de l'argent) !

Non, tu ne dois pas comprendre ça. Comme toujours, tu sautes rapidement aux conclusions et à des généralités pour le moins provocantes. Heureusement, je ne me sens pas concerné par tes propos.

Là où je travaille, la priorité est la qualité et la satisfaction des clients. S’il faut sacrifier du temps supplémentaire pour atteindre notre objectif, nous le faisons. Je suis prêt à parier que c’est aussi le cas de plusieurs entreprises et individus ici et ailleurs.

Artemus24 a écrit :

Dois-je comprendre que vous ne devez presque jamais faire de la maintenance.
Pour moi, cette façon de travailler n'est pas professionnelle, car c'est créer une usine à gaz !

Par maintenance, tu veux dire quoi exactement? Corriger des scripts? Les améliorer?

Pour l’usine à gaz, c’est plutôt facile de tirer une telle conclusion. Tout ce qui est flexible, qui offre plusieurs options variées, peut facilement être qualifié d’usine à gaz puisque qui dit flexibilité et options, dit aussi que certaines options ne seront pas utilisées, mais quand même présentes dans le code. Un système flexible peut être qualifié d'usine à gaz pour un, et de chef-d’œuvre complet pour l'autre.

Artemus24 a écrit :

Ce n'est pas à moi de vous juger car je ne suis pas votre patron, ni votre client !

Pourtant, il me semble que tu portes des jugements très rapidement sur ceux qui utilisent JQuery et les plugins.

Artemus24 a écrit :

Je prends l'exemple d'une Lightbox. J'en ai développé une en Javascript. Le source avec commentaire, non compressé, fait 9Ko. Donc pourquoi devrais-je m'adjoindre une bibliothèque pour obtenir le même résultat ? Et puis, cela correspond exactement à mon attente.

Je n’ai rien contre le sur mesure. C’est ce que je fais chaque jour avec des technologies côté serveur. Je peux très bien comprendre que c’est ce que tu préfères faire.

Artemus24 a écrit :

Une grosse application devrait être développé en jquery car le temps de développement et la volumétrie du source justifie l'adjonction de la framework. Pour ceux qui ne comprennent pas ce que je veux dire, disons qu'en javascript, cela risque de prendre une volumétrie bien plus importante qu'en jquery avec la framework comprise.

Je suis d’accord avec toi. L’utilisation de JQuery prend tout son sens lorsqu’on utilise beaucoup de ses fonctionnalités et qu’on utilise des plugins (ses propres plugins ou des existants). Par contre, je crois que kustolovic disait le contraire.

Artemus24 a écrit :
on parle aussi d'une bibliothèque plus légère. Je veux bien, mais le problème ne se porte pas sur la volumétrie de la Framework, mais sur la volumétrie de la totalité des scripts + Framework. Si l'on peut obtenir une volumétrie moindre pour le même résultat alors je cautionne !

Au prix de ne pas profiter de tous les avantages d’une bibliothèque. À noter qu’il n’y a pas que JQuery. Il en existe d’autres que tu peux personnaliser pour n’inclure que ce que tu as besoin. Je pense à Mootools.

Artemus24 a écrit :

tout le monde n'a pas une ADSL haut débit à sa disposition.

En effet, il existe encore certaines régions où l’Internet Haute Vitesse n’est pas en place et je parle de provinces et de pays riches. Mais 30 Ko à la première visite, ce n’est pas non plus catastrophique. Que celui qui n’a jamais téléchargé une photo coquine de 100Ko avec un modem 56K lève la main.

Artemus24 a écrit :

je vois aussi que les propos de Paolo vont dans le même sens que j'ai énoncé un peu plus haut.

Effectivement, il vaut mieux apprendre les rudiments de Javascript avant d’utiliser JQuery.

Artemus24 a écrit :

Donc selon ma conclusion, le problème que je soulève depuis le début ne concerne pas la volumétrie de la Framework mais d'une part de la volumétrie de tous vos script et d'autre part de votre façon de travailler.

Je dis simplement que vous abusez du Jquery à tord et à travers.

Qui en abuse?

Sans vouloir te vexer, le problème est que tu n’es pas très familier au développement Web et que tu ne peux pas prétendre connaître la façon de travailler des participants de cette discussion. Tu ne peux pas juger de la qualité de leur travail non plus.

Artemus24 a écrit :

Et comme j'ai du temps à perdre car je ne suis pas un professionnel du web, je peux me permettre d'optimiser le code. Mais chacun fait comme il veut !

Un professionnel optimise son code aussi et il doit choisir ses priorités. Entre passer des heures à réécrire des fonctions complètes déjà existantes, testées par des centaines parfois des milliers de personnes pour sauver 10 ou 20 Ko, alors que ce temps pourrait être consacré à optimiser tout le reste, le choix est facile. Évidemment, c'est toujours du cas par cas. Il y a certaines situations où le sur mesure est le meilleur choix.

Sur ce message interminable, je vous souhaite bonne nuit!
Modifié par Tony Monast (11 May 2012 - 04:15)

J'en rajoute, moi-aussi, mon petit laïus…

Artemus24 a écrit :
1) vous avez tendance à tout développer en Jquery alors que l'on a souvent l'équivalent en Javascript.

En fait on a toujours l'équivalent en javascript. jQuery n'est pas un obscur language bizarre mais bien du javascript.

Artemus24 a écrit :
3) beaucoup de professionnels aiment l'usage du copier/coller afin de gagner du temps.

Comme déjà dit, mais le copier/coller de code est plutôt l'apanage des amateurs/bricoleurs qui copie du code sans comprendre ce qu'ils font.

Artemus24 a écrit :
Ils utilisent un Plugins en Jquery dont la totalité (Plugins + Framework) est souvent assez volumineuse. Alors qu'en fait, ils utilisent une seule fonctionnalité de ce qui est proposé.
D'où ma réaction en ce qui concerne ce gaspillage d'espace.

Si on doit se poser des questions quant à l'utilisation de jQuery, les mêmes questions sont valables pour les plugins: Ai-je besoin d'un plugin pour faire ce que je pourrais faire en 2 lignes de jQuery.

Artemus24 a écrit :
4) dois-je comprendre, selon ma troisième remarque, que vous ne développez presque rien et qu'en grande partie, vous faites du copier/coller. C'est un second problème que je dénonce aussi.

Améliorer l'expérience utilisateur, voici ce qu'un professionnel essaie de faire. Pas dilapider la moitié du budget dans la compréhension de bug des navigateurs, alors que cela a déjà été mieux fait. Si vraiment on le souhaite, on peut plutôt contribuer au framework que faire le sien dans son coin.

Artemus24 a écrit :
Dois-je comprendre que vous ne devez presque jamais faire de la maintenance.
Pour moi, cette façon de travailler n'est pas professionnelle, car c'est créer une usine à gaz !

En fait souvent on considère que l'utilisation d'un framework évite l'usine à gaz. En effet avoir beaucoup de code n'est pas une usine à gaz, c'est plutôt d'avoir tout le code mélangé dans un seul système au limites mal définie. (Le code qui fait tout). Plus on a un gros code qui fait tout, la maintenance augmente de façon exponentielle. A tel point que cela devient irréaliste puis impossible à maintenir. Bien sûr on peut se créer son propre système d'accès et de manipulation du dom bien séparé pour éviter ce problème.

Artemus24 a écrit :
5) autre remarque que je trouve pertinente de Kustolovic :

Je suis d'accord avec toi sur ce propos. Une grosse application devrait être développé en jquery car le temps de développement et la volumétrie du source justifie l'adjonction de la framework. Pour ceux qui ne comprennent pas ce que je veux dire, disons qu'en javascript, cela risque de prendre une volumétrie bien plus importante qu'en jquery avec la framework comprise.

Tony l'a remarqué, je disais bien le contraire^^. Pour préciser, Paolo a bien mentionné l'intérêt d'utiliser jQuery pour une grosse application. Je pensais plutôt à une très très grosse appli, qui éventuellement pourrait développer leur propre système optimisé pour leurs besoins. Le genre de projet qui est souvent à l'origine d'un nouveau framework.

Quant à la volumétrie, si tu penses que le javascript serait plus lourd sans jQuery, c'est que tu reconnais que tu n'arrives pas du tout à faire du code autant optimisé? jQuery n'est, une fois encore, que du javascript.

Artemus24 a écrit :
Et comme j'ai du temps à perdre car je ne suis pas un professionnel du web, je peux me permettre d'optimiser le code. Mais chacun fait comme il veut !

Tu n'optimises pas le code, tu remplace un code lourd par un moins lourd mais moins bien conçu. Quelles sont tes connaissances en rapidité d’exécution et utilisation de la mémoire en javascript? Ajoute à cela la problématique du cross-browser, et créer une petite lightbox te prendra 3 semaines de boulot. Et tu devras travailler ensuite beaucoup à chaque fois pour l'adapter, tu y rajouteras au fur et à mesure des corrections de bugs, des faites à la va-vite car tu es stressé sur un autre sujet… au final ta lightbox aura un code lourd, inefficace et sera une bonne vieille usine à gaz…
Modifié par kustolovic (11 May 2012 - 09:47)

Bonjour Tony Monast,

en tout cas merci d'avoir pris le temps d'ouvrir cette discussion et d'y avoir participé.

Je reconnais que j'aime bien jouer la provocation pour connaitre vos réactions.
N'étant pas professionnel du web, toute ma vision se résume aux livres (les conseils) que je possède sur ce sujet et les forums de discussions.
Je consulte parfois les sites et je trouve que ceux-ci sont bien trop volumineux et illisible. Mais bon, cela n'engage que moi.
Je veux signifier que la lisibilité des sites web est pour moi une difficulté. Je ne retrouve pas la qualité du développement qui sied aux professionnels.

"Tony Monast" a écrit :
Je ne sais pas à qui tu t’adresses

A toutes les personnes qui font du web et personne en particulier.

"Tony Monast" a écrit :
Même si je suis d'accord que le Javascript est utilisé très fréquemment maintenant, je n’ai pourtant pas le souvenir qu'il avait été délaissé.

Je t'indique ci-après, l'introduction du livre "Javascript, l'essentiel do code et des commandes" de Christian Wenz aux éditons Pearson.

"Christian Wenz" a écrit :
En 1999, j'ai écrit un livre sur javascript. Au tout début, il s'est très bien vendu puis les ventes ont commencé à diminuer. Elles se sont pourtant stabilisées pour parvenir à la septième édition cet automne, même si un léger déclin se faisait toujours sentir.
Tout a considérablement changé à la fin de l'année dernière : les ventes ont soudain remonté, tout comme celles des autres titres du même segment. Cette évolution tient en partie à AJAX.

L'édition que je possède, l'impression a été achevé le 29 janvier 2009.

"Tony Monast" a écrit :
Là où je travaille, la priorité est la qualité et la satisfaction des clients.

Entièrement d'accord avec toi. Cela devrait être le slogan du service.

"Tony Monast" a écrit :
Par maintenance, tu veux dire quoi exactement?

Cela me parait bizarre que tu ne saches pas ce que sait ?
C'est reprendre un existant (donc ici, un site WEB) afin de corriger des bugs ou de le faire évoluer par l'adjonction de nouvelles fonctionnalités.
C'est souvent faire évoluer un site par une personne qui n'est pas celui qui a développé la première version.

"Tony Monast" a écrit :
Sans vouloir te vexer, le problème est que tu n’es pas très familier au développement Web et que tu ne peux pas prétendre connaître la façon de travailler des participants de cette discussion. Tu ne peux pas juger de la qualité de leur travail non plus.

Tu ne me vexe pas. Mais je ne suis pas ignorant de ce qui se fait dans le cadre du développement. J'ai une expérience d'environ trente ans en tant qu'ingénieur des études dans le cadre des SSII et pour le compte des banques et des assurances. Donc oui, je connais bien les contraintes de cette activité même si elle est différente de mon expérience, elle n'est pas radicalement différente dans le fond.

Si je suis plutôt axé sur le sur mesure, cela vient du fait que nous ne disposons pas (dans le cadre de mon activité) de codes tout fait mise à notre disposition.
A chaque nouveau développement, nous sommes obligés de faire du neuf. C'est une contrainte de notre activité.
Je précise que je suis chef de projet sur gros système et que je développe en Pacbase et Cobol essentiellement. Je suis aussi administrateur DB2.
Je précise tout de même que je connais beaucoup d'autres langages de développement.

@+

Artemus24 a écrit :

Pourquoi parler d'un obscur langage bizarre ?
D'abord, il n'y a rien de bizarre. Tu le dis toi-même, c'est un langage qui possède sa propre syntaxe et ses règles de fonctionnement.

Je suis d'accord que le Jquery [u]repose[/u] sur du Javascript. Mais dire que c'est du javascript, je ne suis pas d'accord. La syntaxe des instructions n'a rien d'équivalent avec du code Javascript. Et si c'est du Javascript comme tu le prétends, à quoi te sert alors la Framework ?

Alors à chaque fois que tu crées une classe ou même des fonctions en JavaScript (ou en PHP ou ce que tu veux) tu appelles ça créer un nouveau langage ? Non mais franchement c'est du grand n'importe quoi. jQuery c'est du JavaScript orienté objet point barre, la syntaxe c'est celle de JavaScript et après c'est juste des méthodes de l'objet jQuery avec leur paramètres.

Bonsoir jb_gfx,

justement, je crois que c'est toi qui n'a rien compris à la programmation objet.

Le but de la programmation objet est de définir de nouveaux outils plus performants que le langage de base dont il est issu. De même on peut tout redéfinir pour les opérateurs.
Un + n'est plus une addition mais peut devenir une concaténation avec de nouvelle règles.

Donc quand je fais x = a + b; que dois-tu comprendre ?
Une addition classique issue du langage de base ou une concaténation issue des nouvelles fonctionnalités ?

Tout dépend du contexte des bibliothèques que tu utilises !
Et c'est toi qui veut me donner une leçon de programmation.

Et je te signale au passage qu'un objet, ce n'est ni plus ni moins qu'un programme contenant des structures de données et des algorithmes. Et les structures de données sont des propriétés et les algorithmes sont des méthodes. Simple question de définitions.

Si tu changes le sens des opérateurs, ou si la syntaxe des instructions n'est plus la même, et bien on nomme cela un nouveau langage. Que cela te déplaise ou pas, c'est ainsi !

@+

Artemus, élu troll de l'année

/respect

Mouais... tu dis pas que des conneries mais t'en dis quand même un bon gros paquet. Si tu sais pas faire la différence entre le langage dans lequel tu écris ton programme : x = a + b; et un paramètre d'une fonction ou d'une méthode comme foo("x = a + b;") je peux pas faire grand chose pour toi.

Peut être que ça existe mais j'ai jamais vu un langage dans lequel tu pourrais redéfinir les opérateurs à la volée au cours de l’exécution d'un programme. Ça serait encore plus tordu que du BrainFuck (c'est un langage de programmation, je précise au cas où).
Modifié par jb_gfx (11 May 2012 - 22:41)

Artemus24 a écrit :

Cela me parait bizarre que tu ne saches pas ce que sait [la maintenance]?

Je demandais surtout pour m'assurer qu'on avait la même définition. Ce mot ne fait pas non plus partie de mon vocabulaire courant. Quand j'effectue des travaux sur un site ou une application Web, j'utilise des termes plus précis : correction de bugs, optimisation du code, développement et/ou intégration de nouveaux modules, tests, etc.

Tony tu t'es fait owned by the troll.

Comme nous tous...

Bonsoir à toutes et à tous,

@ Fabious : j'accepte volontiers d'être un troll au pays des bu(g)s.

"jb_gfx" a écrit :
je peux pas faire grand chose pour toi.

Mais je ne te demande rien !

Le contraire m'aurait étonné surtout en ce qui concerne la programmation et les langages informatiques ! J'ai de ce coté là, bien plus d'expérience que toi en la matière, car j'ai à mon actif la pratique de plusieurs langages ainsi que l'écriture d'un mini compilateur. Mais là, c'est une autre histoire.

Inversement tu as tout à m'apprendre du monde web.

Comme je te l'ai déjà dit et tu as tendance à l'oublier, le monde informatique ne se résume pas au monde du WEB ! Avant l'apparition de l'internet en France en 1995, l'informatique était déjà bien implanté dans les entreprises au cas où tu l'ignorerais. Mais bon, c'est un autre sujet.

@ Tony Monast : ne t'offusque pas, nous avons bien la même définition.
Chez nous, on parle plutôt de maintenance corrective ou de maintenance évolutive.
Nous suivons un cursus différent qui peut se résumer en cinq phases : développement, tests (techniques, fonctionnels et d'intégrations), mise en production, exploitation et maintenance.

"Tony Monast" a écrit :
correction de bugs, optimisation du code, développement et/ou intégration de nouveaux modules, tests, etc. cligne

Peut-être, mais ceci n'est pas de la maintenance.
Correction de bugs --> phase de tests.
Optimisation du code --> phase du développement.
Intégration de nouveaux modules --> phases de tests et en particulier l'intégration.

@ Tous : je crois que nous nous écartons du sujet de base, c'est à dire les raisons de programmer en Jquery plutôt qu'en Javascript.

@+
Modifié par Artemus24 (12 May 2012 - 02:36)

Un passage rapide sur la question du poids de jQuery : il existe un sous-ensemble nommé jQuery in parts, qui fait une sélection parmi les fonctionnalités les plus utilisées et les découpe en plusieurs fichiers pour pouvoir faire du chargement modulaire.

Vous avez aussi la possibilité d'attaquer directement avec Sizzle qui est la sous-lib utilisée par jQuery pour faire de la sélection d'éléments, ce qui est bien souvent la fonctionnalité qui séduit les premiers utilisateurs... avant de pouvoir exploiter querySelector/querySelectorAll (article à venir sur alsacreations.com d'ici 2-3 jours).

dew a écrit :
Un passage rapide sur la question du poids de jQuery : il existe un sous-ensemble nommé jQuery in parts, qui fait une sélection parmi les fonctionnalités les plus utilisées et les découpe en plusieurs fichiers pour pouvoir faire du chargement modulaire.

Mais plus moyen d'utiliser les CDN avec ce système.

Bonsoir Tony Monast,

je ne cherche pas à troller, mais je crois qu'il y a une certaine incompréhension.

Mais j'ai pourtant été clair dans la citation que tu as repris et pourtant, tu as volontairement ou pas occulté la première partie.
Je précise à nouveau : "c'est reprendre un existant".

Corriger un bug dans une phase de tests après avoir fait un développement suite à un nouveau projet, moi je n'appelle pas ça de la maintenance.
Par contre, constaté un bug en production, venir le corriger pour ensuite le remettre en exploitation, ça OUI, c'est de la maintenance.

Le temps que tu consacres à ces deux phases n'est pas du tout le même.
Dans le premier cas, cela peut durer plusieurs semaines, voire des mois puisque ce temps est consacré à la réalisation d'un nouveau projet.
Inversement, le second cas est bloquant et doit être résolu au plus préssé !

Intégrer un nouveau module en exploitation, ce n'est pas de la maintenance.
Mais constater après cette intégration, que les anciennes fonctionnalités ne fonctionnent plus, OUI, ça c'est bien de la maintenance.
Je préciserais d'une part que ce n'est pas la même équipe qui fait l'intégration et le développement et d'autre part qu'il s'agit d'une maintenance corrective et d'un changement de version du logiciel, suite à l'intégration de ce nouveau module.

Bien sûr qu'il y des bugs mineurs, mais en général, elles sont détectés dans la phase des tests fonctionnelles.
Et une phase de tests ne dure pas cinq minutes. Cela peut prendre aussi plusieurs semaines.
A-t-on avis, qu'est-ce qui pourrait se passer, si, suite à un bug nationnal, tous les DAB (distributeur automatique de billets) ne fonctionnent plus ?
Et je ne parle pas d'une indisponibilité du réseau. La première réaction est une énorme engueulade de la part d'un directeur responsable du réseau des DAB.
Car une panne de quelques heures, c'est plusieurs millions d'euros de pertes.

Et après cela, tu crois que nous pouvons nous permettre d'avoir des bugs mineurs dans ce que nous livrons ?

Le code est toujours en évolution car il y a toujours quelques choses à faire. Le plus gros de notre travail est justement la maintenance évolutive.
Et de temps en temps, on fait une migration pour changer de logiciel. Et après cela, on recommence !
Et nous n'avons pas des milliers de clients mais juste un seul : la banque pour qui je travail et je peux te dire que c'est déjà beaucoup.

@+