Il résume tout à fait ce que je pense : les librairies JS allourdissent parfois le code en masquant ce qui est fait. Les natifs « document.getElementById » ou « document.getElementsByName » sont + rapides que les $ utilisés à outrance (d’ailleurs peu clair au niveau syntaxique).

Le top ? Une fonction comme celle-ci qui détermine le meilleur choix à faire :
function objets(id, classe, parent)
{
if (typeof parent==’undefined’)
parent=document.body;

if (id!=null)
return parent.getElementById;
else
return parent.getElementsByClassName(classe);
}

Cette méthode est évidemment à améliorer pour filtrer les balises, les types… Mais elle quand même + rapide que celles analysant les sélecteurs CSS.

Ça me parait un peu expéditif puisque Dom est quand même juste indispensable. Sans compter, que les échanges clients serveurs sont pour la majorité des flux html, xhtml donc XML. De plus, il me semble qu’innerHTML n’appartient pas à DOM. Alors certes, Dom est lent, mais je connais pas mieux sur le marché des apis pour un rendu/ modification/parsage sur nos pages web. Il est recommandation et juste indispensable pour notre web « de surface ».

Pour te punir de ton très vilain article, je te bookmarke et t’obligerais, peut être, dans le futur à subir une fois de plus, mes commentaires 😉

Cordialement ++

Il me parait en effet que l’utilisation d’une librairie JS masque des réalités dont il faut avoir conscience ! Et par exemple l’utilisation aveugle de sélecteurs peut poser problème…
Dans ce sens cet article est bien utile !

Concernant l’optimisation de JQuery, je n’en avais pas entendu parler… Je ne crois pas que les librairies ténor du marché communiquent beaucoup sur ces points ? Dommage…

Pour les lib js, la couche d’abstraction ne te permettra jamais d’optimiser. Tout au plus elle permettra d’utiliser la bonne méthode pour faire une opération. Récupérer un attribut sur un élément HTML, surtout un qui n’a pas besoin de calcul, c’est instinctivement une opération basique. Il serait logique que dans une petite boucle on lise cette information trois ou quatre fois (dans un test ou deux, puis au traitement). Aucune raison de passer par une variable temporaire pour un simple accès d’attribut. Sauf que voilà, si tu sais à quel point DOM est lent, tu feras une variable temporaire, et tu auras raison. La lib js ne te sera d’aucun secours ici. Ce n’est pas son rôle d’ailleurs, elle est là pour faire une couche d’abstraction, soit pour simplifier soit pour uniformiser, aucune n’a la prétention d’optimiser un code javascript (et heureusement parce que le bilan sur les performances est toujours négatif sur ces trucs là).

Utiliser une abstraction et affirmer en conséquence qu’on n’a pas à savoir comment ça fonctionne en dessous sur l’implémentation, c’est le meilleur moyen de faire écrouler les performances, quel que soit le système. On le voit dans les ORM quel que soit le langage, dans les libs js avec les query selector, ou à peu près n’importe où. Les utiliser a beaucoup de sens, je ne dis pas de les supprimer, mais n’attendez pas que ça vous permette d’ignorer les questions de performance (au contraire) ou l’implémentation qu’il y a derrière.

@Pascal : pas à ma connaissance pour le datastore, mais en même temps ça répond à une problématique pas si fréquente. Si tu ne stockes qu’un ou deux attributs à toi par objet DOM, je serai très étonné que le datastore jquery accélère quoi que ce soit (ce sera par contre le cas si tu multiplies les données à stocker pour un même élément), simplement parce que pour fonctionner il doit lui même faire des lectures/écritures dans le DOM (c’est juste qu’il te permet de récupérer toutes les data en un seul coup). Maintenant je n’ai qu’à peine regardé le datastore jquery, simplement parce que au jour le jour ce n’est pas jquery que j’utilise, donc je n’exclue pas de bonnes surprises et d’avoir tort (ou au contraire d’avoir tort mais avec une mauvaise surprise).

Par ailleurs, un des objectifs des bibliothèques javascript est justement de fournir un manière optimisée sur chaque navigateur de faire une opération donnée (par exemple l’ajout de HTML à un endroit). Elles ajoutent une couche d’abstraction qui fait que le codeur n’a pas à chercher à optimiser (entre autre, l’optimisation n’est qu’une problématique) pour chaque type de navigateur.

Si la bibliothèque javascript que vous utilisez ne le fait pas, il faut en changer, ou reporter ceci au mainteneur de la librairie.

à ta connaissance, YUI a-t-il un système équivalent au datastore de Jquery ?

L’exemple le plus frappant est les méthodes qui sélectionnent des élements à partir d’un sélecteur javascript. Si vous en avez réellement besoin, alors ces méthodes sont de très bonnes abstractions. Si vous n’en avez pas vraiment besoin ou si vous n’utilisez une certaine méthode d’accès alors là c’est parfois dramatique.

Sinon oui, attention à la micro-optimisation, mais certains principes restent bons à connaitre. Stocker quelque chose ? si vous n’avez pas de raison de privilégier une méthode ou une autre, maintenant vous utiliserez une variable javascript et pas un attribut sur un élément du DOM. Construire une structure complexe ? le DomFragment est là pour ça, ça ne coute rien mais il faut connaitre, maintenant c’est fait.

Pour ce qui est de l’optimisation aveugle, vu les performances de la plupart des sites « web 2.0 », c’est à voir. Sur un nombre croissant de sites, ce genre de problématique devient réellement significative. Ce n’est d’ailleurs pas pour rien que Jquery a créé un datastore complexe, c’est bien qu’il y a un problème concret à la base. Même chose, quiconque a tenté de créer un tri javascript sur un tableau peut constater de visu la différence entre modifier le tableau directement ou faire passer un display:none avant.

Savoir après si ce sont des choses pertinentes pour *votre* site c’est une autre histoire, mais personne ne pourra y répondre. En attendant le savoir est toujours intéressant.

Autant la performance d’un site est à mes yeux essentielle, autant je pense qu’on doit se méfier de l’optimisation aveugle (premature optimization).