Le code Google Closure n’est pas très propre ?
Je partage cet article de Kevin Yank sur Sitepoint, qui critique le code de Google Closure.
En anglais : http://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/
Pour rappel Google Closure est un ensemble d’outils Javascript qui peuvent être utiles au développement des sites internet.
Depuis que Google nous parle de performances des sites web
- à propos de son impact sur l’indexation,
- avec Page Speed(Extension Firebug pour tester la performance des sites web)
- et SpeedTracer(Extension pour Google Chrome)
- etc,
cet article est un petit cheveu sur la soupe.
Kevin Yank relate diverses portions de code Javascript plutôt mal codées.
Un exemple qui parlera même aux débutants :
- for (var i = fromIndex; i < arr.length; i++) {
Où le calcul de la taille du tableau (arr.length) est fait à chaque tour de boucle, ce qui est plus gourmand en ressources qu’un stockage dans un variable de la taille du tableau.
Cet article ne se contente pas de relever les problèmes dans le code de Google Closure, il présente des solutions pour chaque point. Didactique !
Je suis de plus assez d’accord avec sa conclusion. On a peut-être pas grand chose à dire sur le travail des techniciens Google sur ce point là, mais bon c’est une licence libre et Google bénéficie d’un tel indice de confiance sur le web qu’un tel article peut parfois remettre certaines choses au point.
décembre 20th, 2009 at 19:09
Cet article est très discutable. Ce n’est pas avec une optimisation de boucle qu’on rend une page plus rapide. Le gain apporté par la mise en cache de length est très faible. Déjà, cette propriété est certainement une valeur stockée et n’est donc pas calculée à chaque itération de la boucle. Le gain qu’on peut obtenir provient du fait que l’accès à une variable locale est plus rapide que l’accès à une propriété. Ensuite, à part dans le cadre d’un benchmark, le code contenu dans la boucle aura certainement beaucoup plus d’impact sur les performances que la boucle elle-même.
Dans une bibliothèque aussi énorme, ce n’est pas très difficile de trouver du code qui n’est pas complètement optimal.
L’auteur mets en avant JQuery qui présente selon lui un code de meilleure qualité. Si c’était vraiment le cas, ils n’annonceraient pas des gains de performances de 103% (http://ajaxian.com/archives/jquery-release-126-performance-improvements-and-dimensions-plugin-added-to-core) lorsqu’ils sortent des nouvelles versions.
Dans n’importe quel code, qu’il soit de Google ou de quelqu’un d’autre, il y a du bon, du moyen et du mauvais code…
décembre 20th, 2009 at 19:18
Du mauvais code c’est ça : http://thedailywtf.com/Articles/A-Spacy-Problem.aspx