Hanblog - Tag - DOM - Commentaires

Librairies JavaScript : Connaissez vos outils - S.F.

S.F. — Sun, 14 Sep 2008 15:19:55 +0200

Et que penses-tu de $($('div')[0]).toggle() ?

Librairies JavaScript : Connaissez vos outils - Eric

Eric — Fri, 29 Aug 2008 21:19:24 +0200

Un des points du discours d'Anthony est probablement à propos des horreurs qu'on voit fleurir. Les framework CSS ajoutent des abstractions et trop de gens les utilisent sans comprendre ce que ça fait derrière, ou sans en prendre compte.
Le résultat c'est que ce qui est fait via ces framework peut parfois prendre 10 ou même 10000x plus de temps. Pas forcément à cause du framework lui même, mais plus de sa mauvaise utilisation et du principe même de passer par une abstraction pour quelque chose qui devrait être simple si c'était bien fait.

Le second est assez classique : ne touchez pas la présentation en javascript, jamais. C'est pénible autant pour la maintenance, que pour le développement ou pour les performances.

Librairies JavaScript : Connaissez vos outils - Louis

Louis — Thu, 28 Aug 2008 01:14:16 +0200

Je ne comprend pas ce que tu cherches à montrer. Tu commences en disant que les framework JS c'est le mal, et ensuite tu compares deux fonctions d'un même framework. Je m'attendais à ce que tu compare du code natif et la même fonctionnalité via un code framework.

En fait ce n'est qu'après relecture que je comprend que le point que tu veux souligner, c'est le choix de la fonction framework. Oui, le choix est important. Ca me semble couler de source, mais on peut toujours le rappeler.

Concernant ta conclusion, ton "de plus" est une raison totalement suffisante en soi. Il ne faudrait pas que le fichier JavaScript contienne plus de CSS que le fichier CSS lui-même. Aussi, une bonne pratique est d'utiliser exclusivement des classes dans le JS, à l'exception des éléments de style qui servent uniquement un mécanisme de l'interaction javascript.

Mootools va dans ce sens — dans le bon sens — avec son objet Morph qui permet de passer d'une classe CSS à une autre, en animant toutes les propriétés qui varient.

Nouveautés Safari 3.1 : getElementsByClassName - Olivier D. alias ze kat

Olivier D. alias ze kat — Mon, 09 Jun 2008 12:44:44 +0200

La technique getElementsByClassName est trés interressante car ses performances sont meilleures que tout autre méthodes de sélection même si on ne passe pas par les fonctions natives de Firefox 3 ou Safari 3.
A noter que si on simule cette fonction via XPath, c'est moins bon.
Et pour info, c'est beaucoup plus rapide en Javascript (pour le rendu) de modifier la class d'un element plutot que de modifier ses attributs de style CSS un par un.

Perso, j'utilise une lib* compatible IE6/Firefox2/Safari pour les profiles de LiFE2Front, et çà me permet de faire du tri/filtrage de contenu instantanément avec de bonnes performances. Mais inconvenient ; çà fait grincer Prototype, JQuery, Yahoo! UI, ou Dojo :o(

(*) cliquer sur ma signature pour voir une démo avec mon profil. La lib est citée dans les crédits en bas de page.

Nouveautés Safari 3.1 : getElementsByClassName - Rik

Rik — Fri, 11 Apr 2008 12:20:22 +0200

Déjà, Safari 3.1 est bien sorti :) C'est pour cela que j'ai regardé les libs.

Par contre, mon message est ambigu. Je parlais d'utiliser getElementsByClassName pour leurs recherches basées sur les sélecteurs CSS. Ça demande de changer leur algo (et c'est pas immédiat), mais quel bénéfice pour les utilisateurs.

Par contre, je vais modifier le billet, parce que j'avais oublié de préciser le côté "live" de la liste retournée.

Nouveautés Safari 3.1 : getElementsByClassName - Eric

Eric — Thu, 10 Apr 2008 22:17:38 +0200

Calme, ces navigateurs ne sont pas encore sortis alors laisse le temps aux bibliothèques d'intégrer les nouveautés. Quand au moins un de ces navigateurs sera publié, là on pourra regarder car (malheureusement) certaines lib implémenteront un fallback.

Je dis malheureusement parce que getElementsBy* est le genre de fonctionnalités qu'on ne pourra pas implémenter en javascript. Si fallback il y a il sera incomplet ou différent de la spec et de l'implémentation des navigateurs.

Le problème vient du fait que les navigateurs retournent des listes de noeuds "live", qui sont impactées par les changements dans le DOM. Les bibliothèques ne peuvent que retourner des tableaux statiques contenant des références vers les noeuds DOM.

Demander aux bibliothèques javascript d'implémenter getElementsByClassName quand le navigateur ne le supporte pas c'est leur demander de faire de violer les specs et d'avoir des implémentations divergeantes.

Ils ont choisi de ne pas le faire, et ils ont raison là dessus. Si tu veux un tableau statique de noeuds DOM, toutes ces bibliothèques ont déjà des méthodes pour ça.