Je ne suis pas certain que ça soit encore vrai aujourd'hui pour les performances. jQuery 1.4.2 est devant, je pesne. Les différences entre le 1.3.2 et la 1.4.1 sont déjà énormes et celles entre le 1.4.1 et la 1.4.2 également. Voir ici : Voir ici : http://blog.jquery.com/2010/02/19/jquery-142-released/
A noter que la différence entre 1.4.1 et 1.4.2 est presqu'uniquement dû à l'optimisation de la sélection de "body" qui ne passe plus par Sizzle et n'a plus besoin d'être évalué à chaque fois, mais qui est récupéré directement avec document.body.

Après, ce post ( http://davidwalsh.name/mootools-sizzle ) relativise pas mal aussi et montre qu'on peut changer le sélecteur d'éléments de MooTools et utiliser Sizzle (celui de jQuery) en... 2 lignes - reste à voir ce que ça donne (comment ça s'intègre) pour définir des pseudos-classes personnalisées (si on a besoin).

Les commentaires de ce même billet indiquent également que les tests du dessus sont faux et MooTools s'en sort en réalité mieux que ce qu'on peut voir dans le graphique
La discussion entre les auteurs de MooTools et John Resig (crétateur de jQuery et Sizzle) est résumée ici : http://www.clientcide.com/3rd-party-lib … e-say-wha/

Après, on ne parle ici que des performances des sélecteurs CSS... Et l'histoire n'est pas terminée !

Car après, Sly a été créé , un nouveau moteur de sélection CSS. Voir ici : http://www.garrickcheung.com/javascript … or-engine/
Et MooTools 2.0 prévoit d'inclure Slick, encore un autre moteur de sélection.

C'est compliqué, non ? Hé oui, c'est du gros troll cette histoire. Mais la flexibilité de MooTools permet de choisir son moteur de sélection, ce qui est quand même sympa. je recommande Sly personnellement. :-)

[edit] Un autre point compte désormais (ça n'était pas le cas il y a 1 an voire 2) : les navigateurs récetns (Opera 10.5+, Firefox 3.x+, Chrome ?+ supportent tous querySelectorAll() qui est... une implémentation de Sizzle et Sly directement dans le navigateur. :-) Du coup pour eux c'est natif et ça ne change plus rien.

Dernière fois dit par Savageman (16 Aug. 2010 18:20)

Bien. Mootools 2 a l'air vraiment intéressant du coup. Sly est arrêté au profit de Slick si je comprends bien ? J'ai regardé et fait quelques tests, ça dépote pas mal.

Je me demande pourquoi personne n'utilisait QSA mais c'est sûrement parce que c'est récent (sauf chez Firefox). Tu dis que QSA est une implémentation de Sizzle et Sly directement dans le navigateur. Je ne sais pas pour Webkit, Chakra ou Opera, mais pour Gecko c'est faux. C'est une implémentation en C++ : nsGenericElement.cpp, ligne 5519. nsGenericElement implémente nsIDOMElement principalement mais aussi nsIDOMNodeSelector qui contient QSA (querySelector() et querySelectorAll()). Bon, nsGenericElement est un élément plus complexe que ça encore, mais je nous restreints à ce qui nous intéresse .
Et connaissant les gars de chez Webkit, je doute qu'ils aient fait une implémentation Javascript de QSA. Je mettrais ma main à couper que c'est écrit en C++. Il faudrait chercher dans les sources, je vous laisse le soin de le faire (je connais mieux les sources de Gecko que Webkit).

Tous tes liens étaient intéressants. Ça m'a pris la matinée, mais très intéressants .

Donc juste deux questions : quand sort Mootools 2 ? quel est ton rôle avec Mootools ?

PS : as-tu regardé le compilateur de Hoa CSS3 vers XPath2.0 ? Il supporte tout CSS3 et est même étendable. Par exemple tu peux faire une classe qui hérite de Hoa_Xml_CssToXPath et tu surchages les méthodes callPseudoClass(2), callPseudoElement(2), callPseudoClassFunction(2) et callPseudoElementFunction(2) pour respectivement ajouter des pseudo-classe (:foo), des pseudo-élements (::foo), des fonctions pseudo-classes (:bar()) et des fonctions pseudo-éléments (::bar()).

Oui j'ai vu ce que Symfony a fait mais c'est pas fini. Il ne supporte ni CSS2.1 complètement, ni CSS3 complètement. C'est du partiel. Et je pense que certaines règles de transformations seraient même fausses (pas testé mais au vue des résultats, c'était très étrange). Leur analyseur est régulier alors que la grammaire de CSS3 est algébrique. Je ne vois pas comment ils peuvent bien faire le travail de cette façon. C'est pas mal de bidouillage, comme pour la majorité des analyseurs QSA d'ailleurs … (siffle) .

Hoa_Xml_CssToXPath n'est pas encore terminé, je dois améliorer les lexèmes comme les ID, les strings etc. Du détail car tout le reste fonctionne très bien. Essaye de compiler :

/*a, b, c,*/ * ~ ns|x#y.z[f$=g]:first-child > |* + b, c

Le résultat XPath sera :

descendant-or-self::*//*/following-sibling::*[(@id = "y") and (contains(concat(" ", normalize-space(@class), " "), " z ")) and (substring(@f, string-length(@f) - 0) = "g") and (name() = "ns:x") and (position() = 1)]/:*/following-sibling::*[1]/self::c

Note qu'il est possible de modifier la racine (ici descendant-or-self).
Pour obtenir l'automate au format DOT :

echo new Hoa_Xml_CssToXPath();

Pour le compiler en PNG :

$ dot -v -Tpng -oFoo.png Foo.dot

Le but de Hoathis serait de faire une sorte de bitbucket en fait mais avec des trucs en plus. Et Hoathis serait codé en PHP (et pas en Python) car avec Hoa, et supporterait Mercurial uniquement dans un premier temps.