Discussion :

[souffle56]

Hello gael,
Grand merci pour le code proposé !
C'est vrai que j'avais pas envisagé que ma page aurait un jour 500,000 hits/jour !
Mais bon, après tout, pourquoi pas !

* A ce propos, pour m'aider à me situer, à votre avis, combien de hits/jour pour la page d'accueil de ce site : www.developpez.net
Ca pourrait me donner une idée pour me situer moi-même, toutes proportions gardées, évidemment !

* Pour reprendre cet exemple (ça n'est qu'un exemple !) le chiffre de 500,000 hits/jour -> Ca amènerait à environ combien d'itérations / seconde
(500 000 / 24 heures / 3600 =5.8 itérations / seconde ?)

Sinon, gael, quand tu mets :

J'ai fait un test pour voir les différences de performance.

En executant 10,000 l'opération d'affectation de la largeur en question:

sur chrome:
avec jquery 1.4 : 834ms ; 1.3 : 782ms
sans jquery : 5ms

sur IE8
avec jquery 1.4 : 4100ms
sans jquery : 624ms

donc tu as raison, le carburant coute quand même cher...

->
* Pourrais tu me dire à quoi tu te réfères pour prendre ce chiffre de 10,000 itérations, pour m'aider à "discerner" ?
* Pourrais-tu m'aider à comprendre l'importance de ce genre de test, si possible à partir d'un cas concret ? Ca a à voir avec le débit autorisé par mon hébergeur... ou ?

En te remerciant par avance !

[gael]

Si j'ai fait 10,000 itérations, c'est pour avoir un échantillon significatif et parce que si tu teste le temps d'une seule, tu obtiendras 0. En gros, ce qui ressort du test : jquery est 7 fois moins rapide que du javascript seul sur IE8 et 160 fois moins sur chrome.

Le javascript est exécuté sur le client, il ne faut pas mélanger avec le nombre de hits d'une page. C'était juste pour parler d'une page importante qui se doit d'être optimisée.

Pour les stats de developpez.net:
http://www.quantcast.com/developpez.net
http://www.alexa.com/siteinfo/developpez.net

[souffle56]

Le javascript est exécuté sur le client, il ne faut pas mélanger avec le nombre de hits d'une page. C'était juste pour parler d'une page importante qui se doit d'être optimisée.

Merci pour les explications... je comprends mieux, à présent !

Si j'ai fait 10,000 itérations, c'est pour avoir un échantillon significatif et parce que si tu teste le temps d'une seule, tu obtiendras 0. En gros, ce qui ressort du test : jquery est 7 fois moins rapide que du javascript seul sur IE8 et 160 fois moins sur chrome.

Ok la-dessus, gael; après, ce que je comprends pas, c'est pourquoi n'as tu pas mis 1000 ou 100 ? Effectivement, il y a une différence très significative, dans la vitesse d'éxécution entre les 2 tests; et à ce propos, ton code-test est très pertinent, mais à vrai dire, comme tu le laissais entendre ici :

Enfin, vos exemples sont "légèrement" extrêmes! Ils auraient un sens si la page devait avoir 500,000 hits/jour.
Ici on serait plus en train de savoir s'il faut utiliser un raccourci clavier ou la souris pour copier du texte, et il ne faut pas réfléchir beaucoup avant de prendre une décision pour ne pas y passer plus de temps qu'à effectuer l'action, même si celle choisie n'est pas la meilleure.

-> si je ramène à des conditions réelle d'utilisation, y a t-il vraiment un intérêt à gagner quelques fractions de seconde dans mon code ? D'autant plus que, comme tu le dis :

Le javascript est exécuté sur le client

Si je comprends bien, ça n'a donc pas d'incidence sur mon serveur !

[SpaceFrog]

Il faut tout de même ramener les choses à la réalité de l'utilisateur ...
Je ne suis pas sur qu'il se rende compte de la différence de temps entre 5ms et 782 ms...
Maintenant si on cumule ce genre de délai, là ça devient sensible...
Sans vouloir diminuer la qualité ou l'importance de ton travail souffle56, je ne pense pas que toutes ces considérations, pour une seule opération en dessous de la seconde, soient rédhibitoires.
Ce sont là des digressions de puristes, mais utiles à connaitre le jour ou tu auras besoin de faire 10 000 itérations sur la même page.

[gael]

après, ce que je comprends pas, c'est pourquoi n'as tu pas mis 1000 ou 100 ?

pour avoir un temps > 0 pour la durée d'exécution sans jquery, parce qu'on ne peut pas, à ma connaissance, afficher des fractions de millisecondes.

Ca veut dire que la différence pour une exécution est de 0,077ms sur chrome et 0,34ms sur IE. Ça n'a donc ici aucune importance.

Le javascript est exécuté sur le client
Si je comprends bien, ça n'a donc pas d'incidence sur mon serveur !

Certes, mais c'est qd meme pas une raison. C'est pas pcq le boulanger mange pas tout son pain qu'il en fait du dégueulasse! Et ce n'est pas parce qu'il a ajouté un tout petit peu trop de sel qu'il le sera.

[Bovino]

Vu que la discussion est résolue et part dans des considérations théoriques, je vais en profiter pour y ajouter mon grain de sable

Tout d'abord, l'utilisation excessive des frameworks me gêne un peu parce que bien souvent, elle est motivée, par les débutants en JavaScript par la paresse d'apprendre réellement le langage et l'illusion que le framework accompli des miracles, particulièrement en ajoutant des fonctionnalités au langage.
D'espérience sur le forum, il est très courant de voir des débutants utiliser un framework pour n'utiliser qu'un effet par exemple puis faire (ou pomper) tout le reste de leur code sans utiliser aucune fonctionnalité du framework... Pour reprendre l'exemple de Spaffy, ce n'est même plus prendre la fusée pour aller chercher le pain, c'est la prendre pour y aller, puis rentrer chercher son vélo pour pouvoir rentrer avec !
Pire, on voit parfois des pages avec deux voire plus frameworks qui chacun n'est utilisé que pour une action

Les tests de Gaël ne sont pas étonnants : chaque appel à une propriété du framework lancent tout un tas de fonctions internes qui ralentissent le fonctionnement global (même si jQuery utilise un système de cache interne assez robuste, ça ne comble pas et surtout, ça encombre de la mémoire parfois inutilement). Alors bien sûr, ce n'est pas grave pour un site, mais imaginez comme il arrive souvent, un utilisateur avec Firefox, toute une tripotée de modules dont la plupart inutilisés et avec 4 ou 5 onglets ouverts en quasi permanence sur des sites non optimisés (et donc potentiellement gourmands en ressources mémoire), vous vous retrouvez vite avec un message du type "Oops, Firefox a planté" !

Pour moi, l'utilisation optimale d'un framework est conditionnée par une bonne connaissance de JavaScript et une parfaite connaissance de l'ensemble de la librairie. Ensuite, quasiment chaque instruction doit être pensée en fonction du framework.

Enfin, il est bon de savoir que si jQuery prend actuellement le pas sur ses concurrents, chaque librairie a son propre concept d'utilisation et donc le choix d'un framework n'est pas anodin.
A titre d'exemple, la logique de jQuery est la sélection de collections d'éléments à manipuler par chaînage (jQuery signifie JavaScript Query).
Prototype quant à lui et comme son nom l'indique, s'applique à augmenter le prototypage des différents objets de JavaScript, voire d'en créer de nouveaux.
Dojo vise lui à étendre le modèle orienté objet de JavaScript et à le rendre plus conforme aux "vrais" langages OO.
On voit donc bien que si on veut travailler essentiellement avec des classes, sans que ce soit impossible avec jQuery, ce n'est pas pour autant le meilleur choix

[Bovino]

Ah... j'allais oublier, si, la présence de librairies peut avoir une incidence sur ton serveur !
Certes, une lib n'est pas énorme à charger, mais certaines mauvaises pratiques liées à JavaScript font que contrairement aux autres ressources, les scripts sont chargés de façon synchrones, c'est-à-dire qu'ils bloquent le chargement de la page, donc sachant qu'habituellement, un serveur peut charger au maximum 3 ressources simultanément, si tu as une lib plus un script externe, tu monopolise les deux tiers des tes échanges
D'autre part, le chargement d'un script, mine de rien, c'est une transaction à faire en plus vers le serveur et en règle générale (sauf pour les traitements lourds sur le serveur), la plus grande partie du temps d'échange est précisément la gestion de ces transactions (d'où l'importance du cache navigateur ), donc même si effectivement, sur un "petit site perso" ça n'a pas grande influence, c'est quand même à prendre en compte, surtout si ensuite, il te vient l'idée d'utiliser AJAX à tout va, qui va encore multiplier les sollicitations au serveur !

[Watilin]

Moi y’a un truc que j’apprécie avec les plugins de jQuery, c’est que… On n’est pas obligé de les prendre ! Je travaille en ce moment avec le « core », et pour les deux-trois fonctions dont j’ai eu besoin, je n’ai pas trouvé de plugin faisant exactement ce que je voulais, ou le faisant assez bien (des fois on trouve des plugins mal foutus, mais bon c’est un problème général de l’Open Source).
Alors je bricole mon propre pugin, au moins je sais ce qu’il y a dedans et comment l’utiliser au mieux.

[gael]

Utiliser le cdn de google permet déjà d'éviter de charger son serveur et en plus la librairie est souvent dans le cache du navigateur. Et plus il y aura de sites qui l'utiliseront, plus ça sera vrai.

Code :

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

1
2
3
4
5
 
<script src="http://www.google.com/jsapi" type="text/javascript"></script>
	<script type="text/javascript" charset="utf-8">
		google.load("jquery", "1.4");
	</script>

[SpaceFrog]

en plus la librairie est souvent dans le cache du navigateu

ça se gère au niveau des consignes serveur et dans les header expires ...
Lorsque c'est bien réalisé, le script reste en cache, le temps de chargement ne rentre plus en considération.
Reste le temps d'execution...

[gael]

jquery sur le cdn de google a une durée d'expiration d'un an.

[Bovino]

Le cache de mes navigateurs ont une durée limitée à la session
Et je ne suis pas sûr d'être le seul.

Ceci dit, c'est vrai qu'en passant par Google, tu soulages ton serveur, mais là encore, on en revient à une optimisation que les débutants n'utilisent pas forcément

[souffle56]

Merci à tous,
C'est sympa votre intérêt...

Quand à moi, vu ma situation concrète du moment, je retiens surtout ceci :

Utiliser le cdn de google permet déjà d'éviter de charger son serveur et en plus la librairie est souvent dans le cache du navigateur. Et plus il y aura de sites qui l'utiliseront, plus ça sera vrai.

Code :

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

1
2
3
4
5
 
<script src="http://www.google.com/jsapi" type="text/javascript"></script>
	<script type="text/javascript" charset="utf-8">
		google.load("jquery", "1.4");
	</script>

Pour "soulager" un peu les transactions avec mon serveur
Et puis ceci :

Ce sont là des digressions de puristes, mais utiles à connaitre le jour ou tu auras besoin de faire 10 000 itérations sur la même page.

Je trouve que ça résume bien ma situation, mes besoins du moment, et ceux, en perspective éventuelle, de mes futurs "clients"...
Car, en l'occurrence, si je revenais à du "tout-javascript", le gain que j'aurais actuellement, sur IE8 ne serait que de (4100ms - 624 ms) /10000 = 0,3 millisecondes (pour 1 itération)...

Autrement dit, même si j'avais 100 données à traiter dans la foulée, ça ne représenterait que 0.03 secondes... Du fait, l'affaire est entendue, je continue sur mon alliance javascript - jQuery ! J'sais pas, vous, mais moi, je trouve qu'ils vont plutôt bien ensemble, non ? (évidemment, avec les "précautions d'usage" qu'évoquait notamment Bovino !)

Bonne continuation à vous !

[danielhagnoul]

Bonjour

Je viens de découvrir cette remarquable discussion, on me permettra d’ajouter mon grain de sel. Je n’ai rien à retrancher à ce qui a été dit sur les désavantages apportés par l’usage d’une bibliothèque JavaScript, mais j’ai à dire sur les avantages.

J’ai connu, tout étant relatif, la même discussion passionnée (et certains discutent toujours) entre les partisans de l’assembleur et les nouveaux aficionados du C, puis la discussion repris entre les partisans du C et les évangélistes du C++, et il en fut de même entre C++ et Java, C# et autres langages dits évolués.

Si pour vous asseoir vous n’avez le choix qu’entre un tabouret de bar et un fauteuil, il est évident que le tabouret de bar est moins cher et le fauteuil plus confortable, mais beaucoup plus coûteux et plus difficile à déplacer à travers la pièce. Oui, je sais que les chaises existent, avec ou sans coussin. Comparaison n’est jamais raison, mais cela illustre le propos.

Les performances de jQuery s’améliorent sensiblement au fil des versions et du travail d’optimisation réalisée par l’équipe de développement, mais il ne sera jamais aussi rapide que le JavaScript brut.

Si vous réalisez une page web gourmande en ressource sur un navigateur précis, je vous conseille d’utiliser du JavaScript brut. Si votre travail, comme la vaste majorité, est destiné aussi bien à l’infâme IE6 qu’au performant et futur Chrome 6 en passant par Safari, Opera et autre Mozilla, je vous conseille l’usage d’une bibliothèque JavaScript. Elle vous permettra de consacrer votre temps à la conception de votre œuvre et non à résoudre les particularités de chaque navigateur, et elle vous offrira des bonus.

Revenons à l’objet du test :

Code :

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

$("#monID").width();

width() : "Donne la largeur du premier élément de l'ensemble des éléments appariés".

On peut également donner une nouvelle valeur :

Code :

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

$("#monID").width(400);

"Fixe la largeur de chaque élément de l'ensemble des éléments appariés" mais également

Code :

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

$(".maClasse").width(400);

ce qui modifiera la largeur de tous les éléments du DOM ayant cette classe.

On peut utiliser d'autres dimensions que le pixel :

Code :

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

$(".maClasse").width("40em");

La nouvelle largeur peut être le résultat d'un calcul :

Code :

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

1
2
3
$(".maClasse").width(function(i, oldWidth){
   return (oldWidth + 100 * i);
});

"La fonction doit retourner la nouvelle largeur. Elle reçoit en arguments : le numéro d'index de l'élément dans l'ensemble des éléments appariés et la largeur actuelle de cet élément"

Il y a plusieurs largeurs disponibles :

• Code :

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

  $("#monID").innerWidth();

  
  "Donne la largeur du premier élément de l'ensemble des éléments appariés, cette largeur inclus le padding mais pas la bordure"
  

• Code :

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

  $("#monID").outerWidth();

  
  "Donne la largeur du premier élément de l'ensemble des éléments appariés, cette largeur inclus le padding et la bordure" plus

  Code :

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

  $("#monID").outerWidth(true);

  "Une valeur booléenne indiquant s'il faut inclure la marge de l'élément dans le calcul".

Mais mon ami Bovino a tout à fait raison, ne prenez pas un bazooka pour tuer une mouche et apprenez à vous servir des bases – CSS, HTML, JavaScript – avant d’apprendre à piloter la fusée.

Cordialement, Daniel.

[SpaceFrog]

Mais mon ami Bovino a tout à fait raison, ne prenez pas un bazooka pour tuer une mouche et apprenez à vous servir des bases – CSS, HTML, JavaScript – avant d’apprendre à piloter la fusée.

Mais mon ami Daniel à tout à fait raison, et le vélo ça ne s'oublie pas