Discussion :

[fredoche]

Je conçois tout à fait que JQuery simplifie beaucoup l'utilisation du Javascript, en particulier du DOM. Mais en effet, on se heurte à la problématique expliquée par SylvainPV. Certains (comme mes parents) sont toujours en RE-ADSL (512k), d'autres sont encore en 56k. Dans le village de mes parents, le maximum c'est 2mb. Alors oui un Javascript généré par JQuery, ça se sent (à la fois les performances du code généré que le temps de génération en lui même). On perd jusqu'à plusieurs secondes pour certaines actions. Quand un site est bourré d'effets Javascript, ça impacte de manière non négligeable l'expérience utilisateur. Et je ne parle même pas de la charge serveur, où l'on va faire chercher à chaque utilisateur du site la bibliothèque JQuery, ce qui est une source de ralentissement supplémentaire (en 512k, on télécharge à 60kbps).

Non en ReADSL, en 512 k on télécharge à 512 kbps par seconde et 64 ko/s. On passe donc potentiellement une 20aine de fichiers de 3 ko dans la seconde.( 64 * 8 =512)
Ceci étant la bibliothèque minifiée fait entre 80 et 90 ko selon la version (1 ou 2)

Quand au 56k, il ne fonctionne en réalité que sur des lignes qui sont de bonne qualité. Si la ligne n'est pas éligible à l'adsl, elle est soit trop longue, soit multiplexée. Si elle est trop longue, peu de chances de synchroniser à 56 kbps. Si déja tu as du 28.8 kbps, estime toi heureux.


Connaissant bien le problème puisque moi-même je suis doté d'une ligne de 9km absolument inéligible aussi bien à l'ADSL qu'au 56kbps RTC, il existe des solutions qui permettent de sortir du bas-débit, et avoir du haut, voir du très haut débit, notamment pour des gens qui savent faire un peu d'informatique (généraliste) et qui n'ont pas peur de se prendre par la main. Je ne parle pas de satellite.

Ensuite qu'un site soit bourré d'effets javascript, ça n'a pas de lien avec jquery, je ne crois pas que ce soit en soit une bibliothèque source de ralentissements, leurs algos sont plutôt optimisés.
Et délivrer le fichier jquery plutôt qu'un autre fichier ou une autre image, ça n'a pas plus de conséquence sur un serveur web que la taille du fichier. Un serveur web sert à ça. Délivrer du fichier statique. C'est quasi sans conséquence en terme de charge pour un serveur http.

Si le serveur web est bien configuré (en gros par défaut il l'est), la bibliothèque pourra être "gzipée" avant transfert http et ensuite mise en cache par le navigateur, elle ne se chargera qu'une seule fois pour un chemin donné et une session navigateur donnée. Elle ne générera même pas de nouvelle requête http, vous pouvez vérifier... Même un F5 basique ne recharge pas la bibliothèque (comme les autres fichiers mis en cache: css, js, images...), le serveur répondra "HTTP 304 not modified", et c'est vraiment en forçant la mise à jour du cache (shift+F5)qu'on recharge cette bibliothèque.

En plus de ça, toutes les versions de jquery sont proposées hébergées en CDN, ce qui offre un bénéfice inter-sites et latence énorme, il y a au moins 4 CDN officiels de listés sur jquery.com.

[SylvainPV]

Non en ReADSL, en 512 k on télécharge à 512 kbps par seconde et 64 ko/s. On passe donc potentiellement une 20aine de fichiers de 3 ko dans la seconde.( 64 * 8 =512)

Il faut déduire de la bande passante tout ce qui entoure la data dans le datagramme IP, les indicateurs de trame TCP etc... C'est très variable selon la configuration réseau et la taille des fichiers, mais dans le cas de petits fichiers comme dans ton exemple ça peut être significatif. Ça me rappelle les cours de réseau tout ça

[Zefling]

Ensuite qu'un site soit bourré d'effets javascript, ça n'a pas de lien avec jquery, je ne crois pas que ce soit en soit une bibliothèque source de ralentissements, leurs algos sont plutôt optimisés.

Le problème n'est pas que Jquery ne soit pas optimisé, il l'est. Les problèmes c'est qu'il est plus compliquer d'optimiser des traitements en utilisant Jquery. J'ai eu plusieurs problèmes avec les événements Jquery, où je me suis retrouvé à déplacer une montagne parce qu'il faut traîner toutes les dépendances du framework sur tous les éléments que l'on récupère. Le problème c'est que le traitement n'était pas spécialement léger, et Jquery alourdis les résultats, car forcément pour créer du DOM + Jquery ça prend plus de temps le DOM seul. C'est propre au framework de simplifier, rendre facile d'accès des concepts qu'on aurait mis des jours à faire from scratch, mais forcement au passage certaines choses deviennent forcement un peu plus lourd (et ça me valide pour tous les frameworks que j'ai rencontrés). D'ailleurs, il suffit de se monter son propre petit framework pour s'en rendre compte.

Petit exemple : document.getElementById('example') sera toujours plus rapide que $('#example') (Il suffit de voir la masse de choses que $() fait en plus.)

[fredoche]

Il faut déduire de la bande passante tout ce qui entoure la data dans le datagramme IP, les indicateurs de trame TCP etc... C'est très variable selon la configuration réseau et la taille des fichiers, mais dans le cas de petits fichiers comme dans ton exemple ça peut être significatif. Ça me rappelle les cours de réseau tout ça

rajoute les ACK TCP et les RTT que cela représente, le fait que 80% du trafic internet français utilise ADSL et donc que tout est redécoupé en cellules de 53 octets ATM (dont 48 de payload réel) à partir de trames de 1500 octets ethernet, que le débit sur les offres grand public n'est pas garanti, que la latence est un facteur important, que les utilisateurs sont derrière un routeur NAT...

Le web c'est du réseau, l’internet c'est du réseau, c'est la base du métier à mon sens. On est tout à fait d'accord il me semble. Ce que je voulais dire c'est que là où un fichier de 3ko mettait une seconde à passer en modem RTC, tu en loges 20 ou presque sur une ligne ReADSL minimum.

Enfin pour ma part je fais pas de web grand public, je fais une appli vendue en SaaS, et mes pages mettent toutes moins de 2 secondes à être requêtées, calculées, transférées, affichées sur le client. Pas de fioriture, d'animation plein la vue, juste ce qu'il faut pour que ce soit agréable à utiliser. Je transfère rarement plus de 20 ko par requête utilisateur, le reste est caché depuis l'index de l'appli. Je me suis astreint depuis longtemps aux bonnes règles de ce coté, j'ai de plus toujours travaillé avec ces contraintes, sur la taille et la latence.

Zefling, si jquery est un problème, tu peux éviter le problème, c'est un peu le sens de la discussion et de ce que tu rapportes, d'autant plus si tu as les éléments pour juger de l'utilité ou non. C'est ce qui m'étonne, chaque cas est particulier, et l'idée de mouvement d'opinion ou de "manifeste" me surprend un peu.

[LSMetag]

Non en ReADSL, en 512 k on télécharge à 512 kbps par seconde et 64 ko/s. On passe donc potentiellement une 20aine de fichiers de 3 ko dans la seconde.( 64 * 8 =512)
Ceci étant la bibliothèque minifiée fait entre 80 et 90 ko selon la version (1 ou 2)

Oui, mea culpa. Je m'étais compris mais c'est bien 60ko/s et non 60kb/s.

Connaissant bien le problème puisque moi-même je suis doté d'une ligne de 9km absolument inéligible aussi bien à l'ADSL qu'au 56kbps RTC, il existe des solutions qui permettent de sortir du bas-débit, et avoir du haut, voir du très haut débit, notamment pour des gens qui savent faire un peu d'informatique (généraliste) et qui n'ont pas peur de se prendre par la main. Je ne parle pas de satellite.

Ces personnes s'y connaissant rien qu'un peu en informatique restent une minorité. Les plus "doués" se ruinent en général avec le satellite.

Ensuite qu'un site soit bourré d'effets javascript, ça n'a pas de lien avec jquery, je ne crois pas que ce soit en soit une bibliothèque source de ralentissements, leurs algos sont plutôt optimisés.
Et délivrer le fichier jquery plutôt qu'un autre fichier ou une autre image, ça n'a pas plus de conséquence sur un serveur web que la taille du fichier. Un serveur web sert à ça. Délivrer du fichier statique. C'est quasi sans conséquence en terme de charge pour un serveur http.

JQuery est optimisé je suis tout à fait d'accord. Je dis simplement qu'au lieu d'interpréter du javascript directement, il faut d'abord charger les bibliothèques JQuery, faire la transcription en Javascript à la volée, Javascript qui sera généré donc pas forcément aussi bon que du natif. Pour un site très dynamique bourré de JQuery, l'ensemble des opérations précédentes peut multiplier les temps de réponses. Et en effet, pour des tous petits traitement (un innerhtml), c'est utiliser un buldozer pour couper un brin d'herbe. La problématique serveur est anecdotique, mais on peut la rencontrer si notre site accueille par exemple 1 million d'utilisateurs en simultané. Le serveur a déja beaucoup de choses à gérer pour ce million de personnes. Alors si on rajoute 1 millions de téléchargements en simultané, même si tout petits...

Si le serveur web est bien configuré (en gros par défaut il l'est), la bibliothèque pourra être "gzipée" avant transfert http et ensuite mise en cache par le navigateur, elle ne se chargera qu'une seule fois pour un chemin donné et une session navigateur donnée. Elle ne générera même pas de nouvelle requête http, vous pouvez vérifier... Même un F5 basique ne recharge pas la bibliothèque (comme les autres fichiers mis en cache: css, js, images...), le serveur répondra "HTTP 304 not modified", et c'est vraiment en forçant la mise à jour du cache (shift+F5)qu'on recharge cette bibliothèque.

Ok mais il faut malgré tout la charger 1 fois. 1 à 2 secondes de latence qui pourraient être évités.

En plus de ça, toutes les versions de jquery sont proposées hébergées en CDN, ce qui offre un bénéfice inter-sites et latence énorme, il y a au moins 4 CDN officiels de listés sur jquery.com.

Récupérer sur CDN ou autre acteur externe est une solution en effet. Mais ce sera alors l'acteur externe qui finira par crouler sous les requêtes de tous les utilisateurs de tous les sites utilisant JQuery (entre autres). De plus, je n'aime pas les solutions externes, dont les acteurs bafouent la CNIL (Google par exemple) et utilisent des traceurs.

Pour conclure : pour des besoins de productivité, de coûts de production, dédiés à un public ciblé (Utiliser JQuery sur Facebook ou Tweeter, je sais pas si ce serait une bonne idée par exemple), JQuery et ses alternatives sont supers.

Me concernant, notamment parce que je bosse pour du tout public, je préfère utiliser des solutions comme Dart, qui compile d'abord en Javascript et ne nécessite donc pas de traitements supplémentaires ni de bibliothèques à récupérer.

[Invité]

un petit teste qui montre la différence entre $ et getElement la différence est spectaculaire

[Xinu2010]

Peut-on se passer de jQuery

-> Oui

Doit-on se passer de jQuery

-> Non

[LSMetag]

un petit teste qui montre la différence entre $ et getElement la différence est spectaculaire

Bien résumé.

Un test plus juste (récent) :
http://jsperf.com/native-vs-jquery-data/2

Voici la même avec Dart (Les performances de Dart2JS sont maintenant 25% supérieures (Dart SDK 1.1))
http://jsperf.com/dart-versus-javascript/3

[NaSa]

Tout dépend du site ou de l'application Web à construire.
Si c'est une page avec un malheureux appel ajax et une mise à jour d'une DIV, jQuery est pour moi totalement inutile.

Si c'est une application Web manipulant énormément d'objet, de style et de données, des bibliothèques me paraissent utiles pour faciliter les développements.

Le problème c'est que dles personnes qui ne connaissent pas le Javascript ont plutôt tendance à appliquer les tutos et ...... les librairies.

Ce qui est intéressant, c'est le chargement modulaire de ces librairies. On fait son panier de fonctionnalités, et on génère la librairie, mais on ne trouve plus beaucoup de librairies qui le propose.

[Invité]

Tout dépend du site ou de l'application Web à construire.
Si c'est une page avec un malheureux appel ajax et une mise à jour d'une DIV, jQuery est pour moi totalement inutile.

Si c'est une application Web manipulant énormément d'objet, de style et de données, des bibliothèques me paraissent utiles pour faciliter les développements.

C'est vrai si on ne tient pas compte des évolutions.
Mais si le site grossi et qu'il faut ajouter des fonctionnalités on se tourne vers un pluggin JQuery et il faut tout remettre à niveau ou laisser un vilain mélange

Le problème c'est que dles personnes qui ne connaissent pas le Javascript ont plutôt tendance à appliquer les tutos et ...... les librairies.

Où plutôt le problème c'est qu'ils ne savent pas choisir les bons outils.

[Shuty]

C'est normal qu'il y ait des ralentissement par rapport au js "natif", car en fin de compte jQuery c'est sur une autre façons de développer en JS...

"Write less, do more" (On parle pas de vitess)

[sekaijin]

Bonjour.
Même si je reconnais beaucoup de qualité à JQuery je ne comprends pas comment quelqu'un d'un peu cencé peut dire qu'elle est indispenssable ou même incontournable.

Il existe des librairies qui sont bien plus adapté dans certains contextes que JQuery. et il en est (des contextes) dans lesquels JQuery est particulièrement inadapté.
Je suis peut être un peut torp pargmatique, je choisis un framework ou une lib en fonction du besoin. c'est peut être pour ça que je ne comprends pas cette assertion.

Pour moi JQuery (et elle porte bien son nom "query") est une lib particulièrement bien faite pour chercher quelque chose dans le DOM. C'est sa principale valeur ajouté. les autres caractéristiques se trouvent très aisément ailleurs. La question que je me pose c'est "pourquoi ai-je besoin de chercher quelque chose dans le DOM ?"

Dans 90% de mes dev je ne cherche jamais rien dans le DOM. rares sont les getElementBy... du coup je n'utilise quasiment jamais JQuery.

ALors je réponds sans conteste à la question du sujet
Oui. on peut très avantageusement se passer de JQuery.
et je nuance
Oui il est des cas où JQuery est l'outil le plus approprié.

je continurais donc en fonction du besoin à chercher la meilleur solution.

A+JYT

[jesusnavas]

En lisant la page http://youmightnotneedjquery.com/ juste sur le dernier point (sur le trim) j'ai une petite anecdote qui montre à quel point jQuery est indispensable (selon moi) :

L'autre jour un client m'appelle et me dit qu'il a une erreur de script sur IE8. Je regarde la ligne avec erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ($("#ma_div").html().trim() == "")

qui me renvoie une erreur parce que le div est vide il me semble. Je me dit : "ah jQuery fait pas son job, il est pas cool." Eh ben si il le fait, je pensais que .trim() c'était la fonction jQuery, mais non jQuery c'est $.trim(ma_chaine). Je change ma ligne de javascript par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ($.trim($("#ma_div").html()) == "")

Plus d'erreurs. Sur les compatibilités IE8 depuis que j'utilise jQuery c'est énorme les gains, je ne m'occupe plus de ces problématiques à la con et je peste beaucoup moins sur ce IE8 de ***** à la peau très dure (comment pet-il encore être si utilisé ?).
Les petits gars de jQuery s'occupent gentillement de la compatibilité Firefox, Chrome, Opera, Safari, IE... de la bibliothèque jQuery et moi je concentre sur le reste. J'ai vraiment pas envie de me passer de ce confort là.

C'est pourquoi cette page me laisse dubitatif. Je vois pas l'argument qui ferai qu'on a pas besoin de jQuery. Au contraire, utiliser les codes coté droit et vous aurez pleins de problématiques entre les différents navigateurs. Utilisez le code jQuery sur la gauche (avec la branche 1.xx de jQuery) et fini les problèmes !!!

sekaijin.
Je suis entièrement d'accord avec toi si c'est du pragmatisme ou si pour un projet tu n'en a pas l'utilité ou qu'une autre bibliothèque répondra mieux à ton besoin tu t'en passes aisément.
Mais le document en annexe http://youmightnotneedjquery.com/ à l'air de prôner qu'il est aussi simple d'écrire du javascript de base que du jQuery, ce qui syntaxiquement et (quasi) vrai, mais le jQuery c'est pas juste de la syntaxe.
Comme tu dis, si t'as un projet ou tu dois faire des requêtes .ajax ou utiliser .getJSON ou que tu utilises beaucoup les sélecteurs et tout je trouve idiot de te passer de jQuery ou d'une autre bibliothèque javascript qui vont te résoudre les problématiques de compatibilité entre les navigateurs.

[gorjuce]

passer de jQuery à Angularjs par exemple, c'est en vogue, ca marche pas mal, ca se passe de jQuery.

[LSMetag]

C'est normal qu'il y ait des ralentissement par rapport au js "natif", car en fin de compte jQuery c'est sur une autre façons de développer en JS...

"Write less, do more" (On parle pas de vitess)

Oui mais quand on voit par exemple que le JS généré par Dart égale le JS natif en vitesse (c'est ce qui s'est passé quand j'ai lancé le test ci-dessus sur un Chromium 34), on peut se demander si JQuery est un choix si incontournable.

@sekaijin

On a notre maître Yoda. Le sage a parlé ^^.

@jesusnavas

Et pour ce qui est de la compatibilité, j'ai décidé d'emboîter le pas des développeurs de frameworks JS : pas de support pour IE 8 et inférieur. Message de prévention avec liens pour indiquer au public qu'il lui faut soit Windows 7, soit un Firefox/Chrome/Opera/Safari (pas besoin de droits administrateurs, et il y a aussi des versions portables) quand ils ont XP ou moins. Mon but, c'est de faire avancer les choses, pas de m'abaisser à la médiocrité sachant qu'il y a des solutions faciles à mettre en place pour l'éviter.
Utiliser IE 8 ou moins, c'est un choix qui s'assume, pas une fatalité. Firefox ou Chromium s'installent en tant que simple utilisateur.

[Grabeuh]

J'ai toujours trouvé qu'utiliser JQuery sur de petits sites, c'est comme sortir une pelleteuse pour planter une carotte dans son jardin. Alors oui, on va beaucoup moins se fatiguer qu'avec une pelle et une pioche, mais est-ce bien utile de sortir un engin de 25 tonnes pour faire un trou de 10cm de profondeur ?

Le but de http://youmightnotneedjquery.com/ n'est pas de lancer une guerre ouverte contre JQuery mais de s'attaquer aux développeurs de librairies fainéants qui préfèrent ajouter un dépendance à JQuery et ses 90ko pour pas se compliquer la vie à écrire 20 lignes de plus.
Au final, on se retrouve avec des dizaines de milliers de librairies plutôt intéressantes, mais qui ont une dépendance qui fait 20 fois leur poids.

Ca ne viendrait probablement à l'idée de personne d'inclure un framework en entier juste pour faire une addition ? Ben c'est pourtant une réalité à peine exagérée en Javascript avec JQuery et son API de parcours du DOM, dont tout le monde use et abuse pour réaliser bien souvent une petite tâche mineure qui aurait nécessité au maximum 10 lignes en javascript pur compatible avec tous les navigateurs à partir d'IE8.

Besoin d'un menu déroulant pour un petit site de 4 pages ? Allez, on va prendre un plugin JQuery, qui avec la librairie vont faire 90% du poids du site à eux seuls !

Mais c'est pas grave, tout le monde a de la fibre optique maintenant hein ?

Une pensée pour tous les pauvres bougres qui se tapent encore du 56k ou du EDGE...

[jesusnavas]

Et pour ce qui est de la compatibilité, j'ai décidé d'emboîter le pas des développeurs de frameworks JS : pas de support pour IE 8 et inférieur. Message de prévention avec liens pour indiquer au public qu'il lui faut soit Windows 7, soit un Firefox/Chrome/Opera/Safari (pas besoin de droits administrateurs, et il y a aussi des versions portables) quand ils ont XP ou moins. Mon but, c'est de faire avancer les choses, pas de m'abaisser à la médiocrité sachant qu'il y a des solutions faciles à mettre en place pour l'éviter.
Utiliser IE 8 ou moins, c'est un choix qui s'assume, pas une fatalité. Firefox ou Chromium s'installent en tant que simple utilisateur.

Entièrement d'accord, je me bat sans arrêt avec mon boss pour lui dire qu'on perd beaucoup de temps et d'argent avec IE8. Je tombe des nus quand des grosses boites me disent : "Passer à IE8, non c'est pas programmé pour les 3 prochaines années. Par contre on aime bien les arrondis et les ombré qu'on a vu sur notre iPad." C'est sur que quand j'entends ça j'ai envie de lui cracher à la figure et lui dire d'installer un navigateur qui sait ce que c'est du CSS3 et des standards web, mais le savoir vivre et mon patron me l'interdisent.
En tout cas, pour en revenir au thème, jQuery (branche 1) gère les compatibilités IE8 mais pas seulement. Dès fois il faut aussi se battre entre Chrome, Firefox, Safari, Opera... pour avoir un code js multi-navigateur. Même pour des sites sans gestion de compatibilité IE8 ou j'utilise la branche 2 de jQuery, je suis bien content de pas me retaper des problématiques de compatibilité entre navigateurs.

[LSMetag]

Entièrement d'accord, je me bat sans arrêt avec mon boss pour lui dire qu'on perd beaucoup de temps et d'argent avec IE8. Je tombe des nus quand des grosses boites me disent : "Passer à IE8, non c'est pas programmé pour les 3 prochaines années. Par contre on aime bien les arrondis et les ombré qu'on a vu sur notre iPad." C'est sur que quand j'entends ça j'ai envie de lui cracher à la figure et lui dire d'installer un navigateur qui sait ce que c'est du CSS3 et des standards web, mais le savoir vivre et mon patron me l'interdisent.
En tout cas, pour en revenir au thème, jQuery (branche 1) gère les compatibilités IE8 mais pas seulement. Dès fois il faut aussi se battre entre Chrome, Firefox, Safari, Opera... pour avoir un code js multi-navigateur. Même pour des sites sans gestion de compatibilité IE8 ou j'utilise la branche 2 de jQuery, je suis bien content de pas me retaper des problématiques de compatibilité entre navigateurs.

Oui je te comprends tout à fait. Mais le truc, c'est que maintenant la plupart des "alternatives à JS" le font, au moins au niveau de la branche 2 de JQuery. Et il ne faut pas oublier que si tu fais valider ta page W3C ou WHATWG, ça devrait marcher partout pareil (en excluant évidemment les mauvais élèves comme IE 8 et moins). C'est pour ça que cette histoire de "JQuery indispensable", ça m'interloque. Pour moi c'est juste un outil de productivité et de clarification de code (quoi que ça dépend). Derrière le confort de l'utilisateur n'est pas forcément optimal. C'est maintenant utilisé à tort et à travers pour tout et n'importe quoi, et on se retrouve avec des usines à gaz. Le soucis est évidemment le besoin de maximiser la rentabilité...

[GrandFather]

Petit exemple : document.getElementById('example') sera toujours plus rapide que $('#example') (Il suffit de voir la masse de choses que $() fait en plus.)

Certes. Maintenant, si on utilise jQuery pour des sélections DOM aussi triviales, c'est qu'on a pas compris grand chose à l'intérêt particulier de cette librairie, ses sélecteurs puissants.

[Bovino]

Et pourtant... tu serais surpris du nombre de cas comme ça sur le forum où $() est uniquement utilisé comme raccourci de getElementById()...