Reprise du message précédent :
Je l'ai eu par la mise à jour auto moi ... on me l'a proposé tout seul, j'ai pas eu à aller sur le site

C'est relou ça fait souvent ça

 
Ah tiens, c'est ton site http://beta.nextgeneration.fr ?

Pour clore la discution autour de Firebug, l'update est sur le groupe : http://groups.google.com/group/fir [...] 25cb431a4#

Edit : Ca m'étonnerais moyen que la beta15 et la finale soit une seule et même release

Pourquoi ca serait le cas ? Comment peux-tu l'affirmer ?  

 
En gros rien comme nouvelles features quoi, c'est juste du refactoring

ok
 
ceci dit c'est souvent le cas, si une beta donne satisfaction, elle passe en RC en finale

Le moteur JS de FF3.1 risque de claquer sévère !
http://ejohn.org/blog/tracemonkey/
http://ajaxian.com/archives/javasc [...] in-firefox
 
Pour tester : http://people.mozilla.com/~schrep/image12.html
369ms pour le rendu SANS le JIT, 90ms AVEC
 
Mais bon pour l'instant, avec la dernière nightly (et extJS) ya "quelques" bug

Ouais en parlait justement sur le topic blabla@prog.
 
Pour faire mumuse y'a le repo de tracemonkey :
 
http://hg.mozilla.org/tracemonkey/
 
Ca met un peu de temps à cloner, y'a 38 000 fichiers et 18 000 changesets
 
On peut de la builder le moteur js (Js 1.8).
 
Juste un exemple à la con part rapport au "bench" que j'avais posté y'a quelque jours :
 
 
JavaScript-C 1.7.0 2007-10-03 (Spidermonkey)
 

 
JavaScript-C 1.8.0 pre-release 1 2007-10-03 (Tracemonkey)
 

euh si j ai bien compris ca sera pas le moteur js de la 3.1 mais de la 4 (le temps qu ils etendent le truc, entre autres, au DOM )

'tain moi ça me laisse vraiment froid ce truc
 
d'une part il pouvaient aller chercher autant de perfs plus simplement et plus rapidement (en commençant par des optims simples avant ça), et d'autre part pourquoi d'un coup la vitesse devient prioritaire ?  
 
Il ont passé des années à bouffer de la mémoire comme des ogres et je les soupçonne de continuer dans certains cas.

Développement des ajaxeries, autres outils XUL (et release (prochaine?) de XULRunner) donc rendre le bouzin utilisable niveau vitesse pourrait être une bonne idée, toussa.

Je suis assez d'accord (encore que le problème principal vient du réseau, pas de l'exécution), mais ça accélèrera pas IE 6. Et je répète que cette perfs ils pouvaient l'avoir plus facilement il y a des années sans tenter de créer le moindre buzzword.

du reseau?
demande a nop de te montrer montrer ce qu il a fait chez plein6 ...

c'est pas par un échantillon choisis qu'on démonte une affirmation statistique

bah 10ko de js c est pas exactement ce qui pourrait entrainer un probleme de reseau...

Damn j'avais pas vu

Yup, c'est d'ailleurs un truc qu'a dit l'un des contributeurs principaux de Dojo (en parlant des libs JS): http://alex.dojotoolkit.org/2008/0 [...] that-fast/

Clairement, et pour le moment IE8 a pas l'air de trop trop améliorer le truc.
 
Faut vois si moz arrive à mettre au point IronMonkey son implé de canvas de manière à les propager rapidement dans les moteurs IE (mais vu des posts récents que j'ai lu sur IE/Canvas, ils bossent dessus)

Ouip, mais c'était 0 en termes de ROI

10k+10k+10k ça s'accumule, et au delà de la taille effective du fichier, plus les débits augmentent et plus les problèmes de latence du réseau deviennent importants. C'est d'ailleurs un truc très gênant sur mobiles, les réseaux 3G+ ont beaucoup de débit mais ont encore une forte latence et chaque requête HTTP a un coût notable globalement indépendant de la taille de la réponse.

 
je sais pas précisément de quoi tu parles, mais y'a aussi les données qui transitent en permanence sur le réseau, la petite image quand je fais un hover, les propositions quand je frappe des lettres etc. Et c'est ces trucs là qui font que le web c'est de la merde par rapport à une appli de bureau niveau usage.
 
un truc con : dans facebook (new), dans la barre bleue du haut, c'est un mix d'onglets (home, Nicolas Raynaud, friends, inbox) et de menus (applications, settings), mais comme les menus rament à arriver, on a tendance à cliquer sur les menus, ce qui nous envoie dans un truc qu'on cherche en général pas (on a les mêmes fonctions que dans le menu, mais il faut naviguer plus).
 
comme tout rame, soit tu passes ta vie à mettre des système d'attente (des trucs qui tournent) ce qui te charge encore plus la page, soit ton utilisateur se demande toujours si ça bosse. sachant que la bonne réponse c'est évidemment de fournir un max de trucs immédiatement et de caler ses phases d'attente correctement et en paquet. C'est le genre de trucs avec lesquels je me battais dans mon ancien boulot : on peut faire tourner le calcul pendant 10h au lieu de 12h, si le projet met 1min à s'ouvrir au lieu d'être instantané, le merdier sera moins utilisable.

je confirme pou rla 3G
 
j'ai validé l'intranet sur mon tel en 3G : les chargement de menu via httprequest sont  plus long que lorsqu'on est en bas débit , alors que j'étais connecté en 3G+

Ben oui mais tout ça c'est lié à des problèmes de latence, quand t'as des connections qui atteignent trivialement 1Mo/s effectif en téléchargement une image de 10k elle est récupérée en 10ms (quand à un retour de propositions sur une autocomplétion, ça se chiffre à quelques centaines d'octets, autant dire qu'il n'y a pas de données à transmettre), le problème principal actuellement c'est le temps que met la requête pour faire l'aller et retour entre ta machine et le serveur, et qui est un ordre de grandeur supérieur  
(d'où, typiquement pour les hovers, l'utilisation de techniques genre CSS Sprites)

je suis d'accord hein

edit : enfin sauf sur les sprites qui sont une merde à maintenir dans l'état actuel des choses.

Ben je précisais dans la mesure où t'as répondu que tu voyais pas précisément de quoi je parlais

C'est clairement pas toujours pratique à maintenir (encore que sur les menus ça a tendance à passer à peu près), mais c'est d'une efficacité indéniable pour réduire le nombre de requêtes HTTP

Si justement, c'est le but du projet Tamarin.
 

C'est sur on est loin de l'usabilité d'une appli bureau.  
 
Pour certains trucs d'ui, par exemple les images qui se chargent au "hover", c'est de l'ordre de la méconaissance.
Pour certains trucs qui demanderaient un temps de reaction meilleur, y'a deux cas :

• Les données personnelles : Qui hypothétiquement peuvent être stockées en local (Gear, HTML 5)
• Les données On-demand : Par exemple les find as you type, ou là hormis les trucs genre Comet, y'a pas vraiment d'optim.

Mais concrement comme tu le soulève, il faut savoir gérer le transfert sous forme de prédicat et en gros paté, seulement personne fait ça, parce que e.g demander Page+(1+2) à chaque demande de Page+1 ça leurs fait peur où ils n'y pensent pas. Et y'a aussi les cas où les dev génèrent des requêtes inutiles, pour se "simplifier" la tache, donc récupère du contenu après le chargement de la page.
 
En conclusion, y'a des temps d'attente qui peuvent être évités, d'autre non, les principales raisons c'est le manque d'expérience des dev en matière d'UI et aussi le fait que le web c'est une application client serveur ( Et ça certains dev/decaïdir l'oublient )

Y'a pas que ça : quand tu passes 3 jours à faire des pauvres coins ronds compatibles tous navigateurs, que t'as un composant avec du JS à faire encore, et que t'es en train de te battre contre CSS, ton effort est déjà largement dilué. C'est une telle merde de développer dans ce secteur que faire un simple truc basique qui marche nécessite soit des semaines sois d'être Einstein, les 2 étant très couteux en capital.
 
Par exemple rien que le coup des sprites (ou même des images web en général) c'est la merde, soit tu fais tes sprites à la main et changer un poil de cul nécessite de re-faire ton sprite (changer une couleur nécessite de re-faire toutes les images), soit t'as un outil auto qui te créé le sprite à la volée et ton code serveur devient plus complexe parce que tu as une couche d'indirection en plus, un truc en plus qui est lancé au deploy etc.
Là où une appli cliente/flash/silvermachin/etc. n'aurait probablement même pas eu d'image parce qu'on a des primitives de dessin et on peut faire un gradient ou une ligne côté client de manière efficace.

J'imagine qu'ils cherchent à renverser leur image. Et plutot que de faire des petites optims bienvenue mais finalement peu visible, ils ont préféré faire une optim qui permet de foutre la paté aux autre navigateurs dans certains cas particuliers. Et s en plus ils peuvent mettre un buzzword sur cette optim c'est tout benef vu que les autres navigateurs pedrns du temps à implémenter cette optim pour pouvoir mettre la buzzoptim sur leur fiche technique.

Ils tentent d'imposer le rythme ! on est pas dans la merde

Pour tous les problèmes que tu cites y'a des techniques propres, je pense qu'elles sont surtout pas connues et/ou documentées correctement. Mais encore une fois il ne faut pas oublier qu'on ne parle pas d'une plateforme desktop (Je dis ça mais le web ça m'emmerde au plus haut point pour les problèmes que tu cites, maintenant je doute que tu puisses les inputés directement à la technologie quand tu fais des trucs un tant soit peu "tordus" )

+ 10000

AMHA le pb des applis web c'est qu'on détourne une technologie qui n'était pas faite pour ça. A la base le HTML+HTTP c'est fait pour transmettre des documents liés entre eux, pas pour faire des application interactives.

Dites les gen, il existe un équivalent firebug/drangonfly/visual web dev pour Safari (windows) ?

Le débugger saf' s'appelle Drosera, mais je sais pas si il est dispo sous Windows.

edit:

• Si tu débugges Safari 3.0 ou 3.1, il faut télécharger Drosera. Il est dispo sous Windows.
• Si tu bosses avec les nightlies, le débugger est inclus au web inspector

Resources:
http://trac.webkit.org/wiki/WebDevelopers
http://trac.webkit.org/wiki/Drosera

Clairement, et au final on arrive à faire des trucs pas trop laids

heu non, il est livré avec la 3.1 maintenant je crois.

C'est pas ce que dit le wiki, mais peut-être

Merci

Mais qu'est-ce qu'on en chie pour en arriver là

Il est dans quel menu.

je crois que je confond, est-ce que tu as un menu contextuel "inspect element" sur les pages web ? en fait c'est pas un debugger JS, juste un analyseur de CSS

Au sujet des sprites, la technique pas trop conne qui évite de se taper des calculs à la con, est de mettre les images sur une pseudo grille basée sur un multiple.
exemple :
une grille en 250x50 ou chaque élément est casé dans le 0,0 de chaque case virtuelle de l'image. derrière pour gérer les sprites c'est plus simple, et si tu dois en agrandir un il y a de fortes chances que tu aies encore de la marge sans avoir besoin de tout recalculer, en plus s'est simple à calculer

#menu li  {background:url(spritemenu.png) no-repeat left top;}
#menu li#m1 {background-position:0 0;}
#menu li#m1.current {background-position:0 -50;}
#menu li#m2 {background-position:-250 0;}
#menu li#m2.current {background-position:-250 -50;}
#menu li#m3 {background-position:-500 0;}
#menu li#m3.current {background-position:-500 -50;}
#menu li#m4 {background-position:-750 0;}
#menu li#m4.current {background-position:-750 -50;}
#menu li#m5 {background-position:-1000 0;}
#menu li#m5.current {background-position:-1000 -50;}
#menu li#m6 {background-position:-1250 0;}
#menu li#m6.current {background-position:-1250 -50;}

Et pourquoi y'a pas de background-position-x et background-position-y hein ?
 
NazzTazz