he ben, moi je me suis eloigné il y a longtemps et bien vite de js. A l'époque flash4 paraissait le Saint Graal... Alors maintenant c est son come back... dommage. En meme temps ca me filait des boutons voir des ulceres les lignes de code ;)

misterbrown : adobe utilise au sein de flash un langage : actionscript c'est javascript... (même qu'il a été ouvert et sert de future base pour une prochaine évolution de Firefox) -- bon déjà, évidemment; si on déteste la poésie, ca ne va pas aider pour apprécier le second avènement de javascript. Personnellement, j'apprécie vraiment d'écrire de beaux projets dans des langages tels objective C ou javascript. Il y a une forme de beauté technique quand un langage est en adéquation avec le problème à résoudre.

@oomu : merci

@oomu le principe d'Objective-J est vraiment cool, en effet ! Steve, si tu nous écoutes… mais je crois qu'il a déjà entendu! ;-) Par contre, je ne fais plus confiance à Mozilla pour défendre la communauté open-source et ce, depuis leur "collaboration" (c'est le mot…) avec Adobe sur le projet Tamarin : trop d'ambiguités et la volonté d'Adobe de brouiller les frontières entre actionscript (de type ECMAscript mais propriétaire) et javascript. Il y a danger de confusion…

Bon. Super tout ça. Reste plus à Apple qu'à optimiser les drivers des cartes graphiques avec leurs constructeurs pour avoir les mêmes perfs que sous Ouinedoze et je serai content.

@l'hérétique : icab n'utilise pas webkit ? :-D mdr

Le gros problème de tout ça, ça reste MSIE : dernièrement, un prof de xHTML/CSS section webmaster dans l'enseignement supérieur me disait à propos de Firefox qu'il serait temps qu'il se conforme à la norme de MSIE ! Avec la mentalité de tels fonctionnaires qui font leurs cours dans Frontpage (voire Word [!]) pour une compatibilité avec MSIE 6 sur des bécanes sous Win 2000, comment voulez-vous que les choses avancent vraiment ? Je vous rassure, j'ai changé d'école pour la rentrée. Mais ils auront réussi leur coup : j'ai perdu 6 mois à étudier des conneries. Et je sais qu'ils continuent à former des cancres.

"Euh... pas chez moi. J'utilise les nightly de WebKit et Firefox 3.1 avec TraceMonkey activé, et il est en retrait. Sur Dromaeo aussi du reste." Il t'a dit "Par exemple, si tu compares avec cet outil TraceMonkey au moteur actuel de safari! " pourquoi tu parles alors des nightly de webkit. L'actuelle version de Safari (si tu piges pas cela veut dire la version 3.1.2) n'intègre pas SquirrelFish et cette version est belle et bien lus lente que Firefox 3.1 avec TraceMonkey activé sur SunSpider. "D’autres séries de tests réalisés avec Dromaeo confèrent à Chrome un léger avantage." Sur le site sur lequel vous faites référence, Chrome est plus lent sur Dromeo que Firefox et Safari Webkit. On y lit les résultats suivants: Google Chrome Nightly Windows - 13478.20ms (Total) Mozilla Firefox Nightly Windows - 7779.40ms (Total) Safari WebKit Nightly Windows - 7586.80ms (Total) Les graphiques font référence au nombre de tests realisés par minutes donc plus c'est grand plus c'est mieux. D'ailleurs le même test reaslisé sur OS X montre des resultats encore meilleur. Firefox Nightly on OS X - 6648.20ms (Total) WebKit Nightly on OS X - 4387.20ms (Total) Merci de corriger.

On peut vraiment aller sur des sites avec du Java avec Safari ? C'est pas en bêta cette fonction ? Je dis ça parce que chez moi, une visite sur Facebook ou Gmail et je suis souvent obligé de rebooter l'iMac ...

oui moi je veux bien tous ces chiffres qui me parlent pas du tout tout ce que je sais, c'est qu'une vidéo un peu longue sur youtube et hop -> ventilo du macbook pro santa rosa qui s'énervent. sans parler de tous ces sites incompatibles avec Safari ou il faut démarrer l'usine à gaz firefox pour en profiter. A allez vers des hiéroglyphes de plus en plus complexes, n'en n'oublions pas les bases svp

Pas mal cette concurrence. On est tous gagnant :-) 2Bad

Donc si j'ai bien pigé, Apple développe une appli d'étude des perfs javascript des navigateurs, appli qui donne gagnant le navigateur d'Apple. Apple, juge et partie ? On n'est jamais si bien servi que par soi-même…

"Donc si j'ai bien pigé, Apple développe une appli d'étude des perfs javascript des navigateurs, appli qui donne gagnant le navigateur d'Apple. Apple, juge et partie ? On n'est jamais si bien servi que par soi-même…" Bien non tu n'as rien pigé. SunSpider est un outil mis au point par l'équipe de Webkit pour juger des perf. JavaScript! Mais il ne favorise pas Webkit, d'ailleurs ça n'a pas de sens techniquement de le penser! SunSpider existe depuis un moment maintenant! Par exemple, si tu compares avec cet outil TraceMonkey au moteur actuel de safari, TraceMonkey fera mieux!! Je te laisse conclure! D'ailleurs Mozilla utilise aussi souvent cet outil pour faire des comparaisons de perf.

sunspider et Dromaeo sont 2 outils très populaire pour tester et ARRETEZ de voir PAUL et MICK partout ! bonsang, je vous le jure, tout va bien, c'est un progrès, apple fait son boulot, mozilla aussi, et tout le monde est content et on se frotte les mains à se dire qu'on va pouvoir concevoir de bien beaux outils grâce à toutes ces améliorations. - sinon, en fait cette fulgurante amélioration n'est pas tant une surprise. jusqu'à présent, js était vécu comme un langage de "script", c'est à dire des petites commandes pour automatiser un site web. des petits traitements légers et rigolos. puis google a commencé à pousser très loin js (javascript), avec ses googleries.. bon. mais surtout, devant la lenteur pachidermique de microsoft et le manque de volonté du W3C, un conglomérat de passionnés du web et d'entreprises ont proposé (x)HTML 5 et beaucoup , beaucoup de services intégrés DANS le navigateur. à partir de ce moment, pour pouvoir profiter de tout cela, Javascript est devenu stratégique, vital, indispensable. Firefox, opera, safari se sont mis à gérer des préversions de css 3 et html 5 (canvas, ombrages, stockage local persistant, vidéo embarqué, etc) tant de choses directement exploitables nativement par Javascript (la magie de DOM pour parler technique). Bref, maintenant, on a envie d'un javascript RAPIDE ! du coup, toutes les techniques utilisées au sein de Perl, Java (qui n'a rien à voir avec javascript, sisi, je vous le jure), et autres langages dynamiques interprétés ou pseudo-compilés (plus des nouvelles récentes super-cool dans les labos) sont mises à contributions forcément, le gain est spectaculaire. Nous passons d'interprétation basique tels les petits scripts du terminal unix à de véritables moteurs de machines virtuelles avec code natif optimisé de l'ensemble des fonctionnalité de javascript (par exemple la bibliothèque d'expression régulière de Apple rajoutée au sein de safari 4, en C. ) cela change tout.

c'est aussi le nouveau champs qui excite les hackers les plus roxxors :)

Ou au contraire, le fait de mettre BEAUCOUP de Javascript sur tous les sites, pousseront les utilisateurs de Internet Explorer à ne plus utiliser cette bouse et passer sur Safari, Chrome ou Firefox. Comment dirent aux utilisateurs d'IE d'arrêter d'utiliser cette merde ? Développer un site moderne CSS + XHTML pour Opéra, Firefox, Chrome ou Safari est facile. Mais faire qu'il fonctionne aussi sur IE est quasiment mission impossible... L'extinction de IE serait une bonne chose pour internet.

La très rapide progression n'est pas exceptionnelle. C'est juste qu'à la base JavaScript à été développé pour faire bouger du texte dans une page ou faire des rollover sur une image, attacher un ou deux évènements à un éléments... Et les moteurs ont été développé pour cet usage, pas besoin de perf ! Maintenant avec les applis comme GMail, Google Docs, MobileMe... et des frameworks comme Cappuccino demande une puissance plus importante aux moteurs JS, du coup ils sont redéveloppé avec cet objectif en tête et ça va plus vite ^^. C'est aussi pour ça que les redéveloppement sont privilégié et marche mieux que les améliorations de moteurs déjà existant : les anciens moteurs n'étaient pas du tout pensé pour ça.

"Firefox, opera, safari se sont mis à gérer des préversions de css 3 et html 5 (canvas, ombrages, stockage local persistant, vidéo embarqué, etc) tant de choses directement exploitables nativement par Javascript (la magie de DOM pour parler technique)." Quel est le lien entre XML DOM et le CS3 et l'HTML 5 ? Idem pour la vidéo embarquée, etc ... Je comprends que Javascript emploie DOM (pour modéliser une page HTML par exemple) mais je ne vois pas le lien que tu fais ... Si tu pouvais détailler un peu... MERCI :-)

Je souhaiterai rajouter qu'au Google Developper Day 2008 de jeudi dernier, le responsable de V8 a fait une excellente présentation de la compilation "à la volée" de JavaScript dans Chrome. Quand je lui ai demandé pourquoi avoir utilisé le projet WebKit et pas le projet SquirrelFish attenant, il m'a répondu que c'était uniquement parce que Google n'était pas au courant de ce développement au moment où ils ont décidé de développer Chrome. Du coup, ça fait un 3ème projet open-source d'"optimisation" du Javascript. Peut-être que Microsoft pourrait utiliser un de ces projets au lieu de réinventer la roue. Mais mon petit doigt me dit à l'instant qu'il ne faut pas trop compter dessus avec la politique propriétaire de Microsoft.

Il y a un truc qui m'éclate, c'est qu'on entre dans une voie où on va développer des milliers de lignes en javascript pour faire des choses qui sont implémentées en standard dans les OS. Quand un développeur veut mettre en place un bouton, une case à cocher, un bouton radio, une liste déroulante, ... il fait appel à un objet HTML, lequel référence un objet standard de l'OS. Par contre, quand il veut un menu déroulant, un onglet ou un effet de transparence, il va inclure dans son code une bibliothèque Javascript qui va refaire ce qui existe déjà dans l'OS. En plus, il a le choix entre des dizaines de bibliothèques javascript, plus ou moins bien développées et dont 90% auront disparu dans 2 ans. Quid de la pérénité du code et des investissements ? Oui, c'est sympa de faire du javascript pour rendre l'interface plus conviviale et ergonomique. Mais en se basant sur des objets existants, pas en les réinventant.

" Comment dirent aux utilisateurs d'IE d'arrêter d'utiliser cette merde ? Développer un site moderne CSS + XHTML pour Opéra, Firefox, Chrome ou Safari est facile. Mais faire qu'il fonctionne aussi sur IE est quasiment mission impossible... L'extinction de IE serait une bonne chose pour internet." Malheureusement , ce foutu IE plombe l'innovation Deja, y'a un nombre pas possible de boulets qui utilisent encore IE 6 ! .C'est typiquement le genre de personnes qui ne mettent jamais leurs logiciels a jours et ils sont legions ! Comment veux tu que ces gens passent sous Firefox ou Chrome ??? impossible pour eux ; ils sont condamnés à utiliser les logiciels préinstallés

"Quel est le lien entre XML DOM et le CS3 et l'HTML 5 ? Idem pour la vidéo embarquée, etc ... Je comprends que Javascript emploie DOM (pour modéliser une page HTML par exemple) mais je ne vois pas le lien que tu fais ... Si tu pouvais détailler un peu... MERCI :-) " alors, nous sommes d'accord que HTML est un langage à balise qui décrit la mise en page d'un document textuel (puis devenu multimédia) pourtant, je dis bien : "dans le cadre de html 5, fut standardisé l'ajout de la vidéo, le stockage persistant, le canvas etc." quid?! ben le groupe qui a poussé tout cela, le "whatwg" (avant de rejoindre le WC3 qui a vu la Lumière) n'était pas constitué de puristes. oui, le terme est un peu fourre-tout, on dit HTML 5 pour dire "tout ce qui va débarquer dans les navigateurs" mais ce n'est pas totalement si faux. ainsi, quand html 5 définit le tag , il définit aussi comment le canvas se comporte, comment on dessine dans ce "canvas", comment javascript le voit, etc quand on définit au sein de dom comment le stockage persistant se voit, on définit aussi le gluant avec html et javascript bref, c'est transversal et le w3c a les beaux papiers avec les termes sérieux et pros, mais globalement, dites vous que dans le cadre de la normalisation de HTML 5, ce sont surtout de nouveaux services des navigateurs webs qui sont poussés. Parce que ses auteurs en avaient marre de la pauvreté fonctionnelle des navigateurs alors qu'on nous vendait le "web 2.0"

justement, le but est de se débarrasser des "frameworks" javascript qui réinventent des fonctionnalités natives des systèmes d'exploitation (par exemple la Composition graphique et transparence comme signalée dans un commentaire plus haut) CSS 3 apporte tout ce qu'il faut pour des design de page web impressionnant jouant sur les contours des objets, la transparence, les bordures sophistiquées, etc. Pour Firefox ou Safari, ils s'agira juste de s'appuyer sur les fonctions natives de os X. pour moi, en tant que développeur, je n'aurais plus à copier-coller dans mon projet toute la Lib Yahoo qui simulait de beaux effets je n'aurais qu'à m'appuyer sur les fonctions natives du navigateur, qui lui pourra mettre cela en oeuvre avec du code natif à la plateforme, conçu pour, donc bien plus rapide les bibliothèques Yahoo ou google muteront en des outils qui mettront en oeuvre les fonctionnalités natives du système en une forme plus adapté à un problème spécifiques, que sais je ? mais à mon sens, l'avenir est dans les "cadres de développements" ou "cadre applicatif" (en anglais : Framework, l'étape conceptuelle après la "bibliothèque") tel sproutcore ou cappucino. Jusqu'au jour où Javascript sera équipé par défaut d'un "cadre" standardisé et fournit au sein de tous les navigateurs, sur lequel je pourrai compter pour mettre en oeuvre de manière efficace et cohérente tous les services dont j'ai besoin pour mon application web. Cela dit, ce n'est pas obligatoire. html/css/javascript forme la "plateforme", et le cadre est par dessus. Il y en aura pour tous les goûts. - Pour l'utilisateur y a 2 choses : - plus le navigateur intègre de fonctionnalités développeurs plus les applications web peuvent être légères ou s'occuper de choses plus intéressantes. - ces fonctionnalités ont la possibilité d'exploiter intimement le système d'exploitation

"Il y a un truc qui m'éclate, c'est qu'on entre dans une voie où on va développer des milliers de lignes en javascript pour faire des choses qui sont implémentées en standard dans les OS. " comme dit plus haut, c'est vraiment ce soucis là que html 5 veut gommer. que ces concepteurs ont eu marre. Rome ne se fera pas en 2 jours imaginez donc qu'on espère figer html 5 en 2012 (!) que le (titanesque) chantier est de réinventer les formulaires (non, PAS xforms !) et que bien sur, il faudra ensuite penser à apporter des "contrôles" de qualité et sophistiqués tel menu, glissette, etc. - pour la pérennité je m'inquiète pas. Quasiment toutes les bibliothèques et cadres de développements javascript sont opensource ou carrément logiciel libre. Ils mourront quand plus personne ne les désireront. prototype est actif, django est très vivant, et j'en passe. Bien sur faut savoir avoir le nez fin. Sentir le vent, tater la communauté, juger si le projet a une pertinence. Ainsi Rails (pas tout à fait la même chose que les libs javascript) avait une pertinence, il répondait à une demande (forte), on pouvait en toute logique se dire qu'on en avait pour quelques années tranquilles avec. la Yahoo User Interface Library, bon.. et bien y a yahoo derrière. Même si yahoo mourrait, le code serait encore en bonne santé et maintenu par beaucoup de gens pour un moment.

"Malheureusement , ce foutu IE plombe l'innovation Deja, y'a un nombre pas possible de boulets qui utilisent encore IE 6 ! .C'est typiquement le genre de personnes qui ne mettent jamais leurs logiciels a jours et ils sont legions ! " oui, c'est vraiment problèmatique. quand vous développez des outils pour entreprise, vous êtes encore forcés de penser à ie6 ! et ce n'est pas qu'une gêne parce qu'on est amoureux de la culture de Liberté de Mozilla (Etendard au vent, cheveux fous ! Libertadaaa !) non, c'est aussi que du coup on ne peut pas forcément utiliser les outils les plus excitant du jours, les moyens les plus modernes et faciles, on se retrouve à un moment ou un autre , confronté à l'horreur abyssale du vide de ie 6. Quand on a touché à firebug (firefox) ou l'inspecteur web de safari 4, tester son code sous ie6 fait grincer les dents. heureusement, IE 8 apporte bien plus d'aide que ie6/7. J'avoues que la plateforme windows me barbant depuis longtemps, je n'ai pas encore regardé de près ce qu'apporte ie8. Je le ferai dans le cadre de mon boulot. -- je m'attends à ce qu'un jour Xcode soit capable de débugger safari à chaud, et là je tombe à la renverse. mais je devrai ENCORE lire la console IE6 pour débugguer ie _6_.

On a cité des framewrks comme sproutcore, capuccino, etc. On oublie de mentionner un petit bijou que j'utilise et dont le web regorge de plugins, c'est JQuery. Je crois que la prochaine bataille du web se jouera du coté des machines mobiles. Et là Microsoft risque d'avoir vraiment du mal. Mais qui sait?