Sortie de jQuery-1.3
jQuery-1.3 vient juste d’être publié. Une grande partie du travail a consisté à rendre jQuery encore plus rapide, notamment sur la sélection et l’injection de code HTML. Des progrès ont également été apportés dans le domaine de la compatibilité entre navigateurs (ce qui est en fait l’un des premiers objectifs d’un framework javascript).
Outre cela, il y a deux changements majeurs à noter, sur lesquels je voudrais revenir : Sizzle et .live() .
Le nouveau sélecteur Sizzle
John Resig nous avait déjà promis un nouveau moteur de sélection, Sizzle. Il promettait qu’il serait environ quatre fois plus rapide que celui des autres frameworks. Si on en croit les benchmarks publiés, ce n’est bien sûr pas le cas mais il n’en reste pas moins que ce moteur est plus rapide que les autres (et même beaucoup plus rapide que ceux de Prototype et Mootools).
Mais si cela est intéressant en soi, il y a une autre surprise derrière Sizzle, relativement inatendue et qui me semble d’un grand intérêt : il est réalisé de manière indépendante à jQuery et un appel à été lancé aux développeurs des autres frameworks pour y contribuer.
Le but de Sizzle est donc à la fois d’être d’une performance sans égal et de faire converger les énergies (l’un entraînant l’autre et vice-versa). C’est une belle initiative, nous verrons ce que cela donnera. On peut soit s’attendre à une incompatibilité totale de points de vues, et ce ne sera que “le sélecteur de jQuery qui peut aussi être utilisé tout seul”, soit s’attendre à voir émerger de ceci un standard sur la sélection en javascript. Time will tell…
Les Live events
C’est ici, à mon avis, le changement le plus excitant. Ce n’est pas tout à fait révolutionnaire parce qu’il ne s’agit en fait que d’intégrer le plugin Live Query de Brandon Aaron. Néanmoins, l’intégrer dans le core de jQuery va permettre d’en faire une utilisation plus naturelle et systématique (et ne plus se poser la question : “est-ce que ça vaut le coup que j’intègre un plugin juste pour cette petite fonctionalité que je veux rajouter?”).
En quoi consiste ces live events? Lorsque vous attachez un événement, vous l’attachez à un élément du DOM. Il faut donc que cet élément existe. Considérons ce bout de code :
$( '#menu li' ).click( function(){ $(this).une_fonction(); } ); $( '#menu' ).append( ' <li>nouvelle option</li> ' );
Le nouveau li ici n’aura pas l’événement voulu attaché, seuls les autres executeront une_fonction() lorsqu’ils seront clickés.
Avec la fonction .live(), vous attachez l’événement non plus à un élément du DOM mais à un sélecteur (du moins, c’est l’impression donnée à l’usage, je passe l’implémentation technique). Ainsi, vous pouvez faire :
$( '#menu li' ).live( 'click', function(){ $(this).une_fonction(); } ); $( '#menu' ).append( ' <li>;nouvelle option</li> ' );
Ici, le nouveau li répondra à l’événement défini. Pour annuler le live event, il suffit de passer .die() au même sélecteur. De plus, die() permet de choisir quel événement supprimer : tous, tous ceux qui correspondent à un type d’événement particulier ou encore tous ceux qui corespondent à une fonction particulière, soit :
$( '#content .popup' ).die() ; $( '#content .popup' ).die( 'click' ) ; $( '#content .popup' ).die( 'click', turnBackgroundDark ) ;
La où cela devient vraiment intéressant, c’est quand on combine live() avec la puissance des sélecteurs. Ainsi, imaginons qu’on ait une liste d’utilisateurs, certains en-ligne et d’autres hors-ligne, avec des fonctions ajax qui vérifient si les utilisateurs arrivent ou partent et modifient leur status en conséquence. Nous voulons que l’utilisateur puisse démarrer une conversation avec les utilisateurs en ligne :
$( 'ul#users li:contains( 'en-ligne' ) ).live( 'click', function(){ startChat(this); } );
L’événement click sera automatiquement ajouté et supprimé selon le status de l’utilisateur.
14 janvier, 2009 à 18:44
Sortie de jQuery-1.3 - Olivier El Mekki…
jQuery-1.3 vient de sortir. Review de cette version….
17 janvier, 2009 à 21:03
J’ai découvert ce framework depuis peu et je commence à travailler avec dans le cadre d’un projet interne.
Je dois dire qu’il tourne vraiment bien.
Et même si je le trouve encore obscur par moments je pense que je vais définitivement l’adopter (j’avais testé Prototype mais il ne m’avait pas autant accroché).
17 janvier, 2009 à 21:42
Oui, il est clairement séduisant. Je leur préfère aussi à prototype pour des questions purement de design interne (genre, le fait qu’il soit vraiment pensé pour ne pas provoquer de collision avec les autres libs), et je le préfère aussi de loin à mootools, qui est un peu à jQuery ce que le C est à ruby ou python dans le domaine applicatif :)
D’ailleurs, je pense qu’on peut dire que nous ne sommes en rien des originaux dans cette préférence :) http://www.google.com/trends?q=jquery%2C+scriptaculous%2C+mootools&ctab=0&geo=all&date=all&sort=0
21 janvier, 2009 à 20:21
Ah oui quand-même !
Je pensais pas que c’était à ce point…