Affichage des articles dont le libellé est javascript. Afficher tous les articles
Affichage des articles dont le libellé est javascript. Afficher tous les articles

22 septembre 2008

Lors du Google Developer Day, une session (la plus technique) était consacrée à Chrome, et plus précisément à son moteur JavaScript très sophistiqué visant à obtenir (enfin) de très bonnes performances en JavaScript. La concurrence avec SquirrelFish (projet similaire de WebKit) a été évoquée, et il est surprenant que Google, tout en investissant sur WebKit, n'ait pas vu venir ce projet et préféré faire cavalier seul.

Quoi qu'il en soit, SquirrelFish relance la guerre des bench et des records avec une nouvelle version "extreme", encore plus mieux. Google v8 va t-il réussir à surenchérir ?
Qu'est ce qu'on gagne dans tout ça ? Tout d'abord, la démonstration que du code JavaScript PEUT être rapide. Si l'équipe de Firefox doit se tâter pour choisir son futur moteur JS, c'est surtout du côté d'Internet Explorer que la pression va monter :

Jusqu'ici l'utilisateur lambda n'avait pas trop de raison d'abandonner son IE, installé par défaut (le "par défaut" étant un atout d'une puissance sans égal). Parmi les quelques curieux qui ont entendu parler de Firefox aux infos comme record du logiciel le plus téléchargé, 1% (?) pourront aller jusqu'à l'installer pour voir. Actuellement, ça ne changera pas leur vie et il garderont leurs habitudes. 

Mais demain ? Si Firefox lance et exécute leur webmail "orange" (ou alice ou neuf ou ...) en trois fois moins de temps que leur vieux IE, là ça pourrait donner des idées. IE8 n'a donc pas d'autre choix (IMHO) que de développer un moteur JS raisonnablement performant.

Qui gagnera la course à la rapidité du JavaScript ? Les utilisateurs !



04 juin 2008

du javascript ... compilé ?

Les applications "web 2.0" utilisent de grandes quantités de JavaScript. Les librairies écrites dans ce langage font preuve de beaucoup d'effort pour obtenir les meilleurs résultats sans sacrifier une bonne structuration, mais les performances reposent toujours sur l'interpréteur JS du navigateur.

Si sur un PC "moderne" cela pose relativement peu de problème, c'est loin d'être le cas pour le marché du web mobile. Il est hors de question de faire ingurgiter des centaines de ko de script à un navigateur mobile en espérant des performances de haut niveau.

Or c'est le marché le plus porteur du web de demain ! Certains site orientés mobiles observent déjà une avalanche de requêtes "iPhone". Non pas qu'il y ait des millions d'utilisateurs du joujou d'Apple, mais plutôt que ceux-ci utilisent leur mobile comme station web, connectée en permanence, et donc ont un comportement très différent de l'utilisateur classique qui garde un oeil sur son forfait WAP 1h ;-)

Les développeurs de WebKit (le moteur commun des navigateurs KDE et Safari) annoncent leur projet SquirrelFish - comment peut on trouver des noms pareils ;-)
Il s'agit d'un moteur JavaScript utilisant un mode "compilé" des scripts sous forme de bytecode, ce qui permet d'excellentes performances.

Ils proposent également un benchmark qui permet de se faire sa propre opinion
http://webkit.org/perf/sunspider-0.9/sunspider-driver.html

Pour moi, ça donne sur mon PC (windows XP) :

IE7 : 46 172 ms
IE8 beta : ne s'installe pas chez moi, problème d'update invalide :-( il faut une version US ?
Firefox 2 : 34 946 ms
Firefox 3 rc1 : 5 256 ms
Safari 3 : 6 690ms
Safari + Webkit "nightly build" : 4 859ms -- soit presque 10fois mieux que IE7 !!

Bien sur, comme toujours, ce bench est probablement discutable et les résultats sur un seul PC ne sont pas représentatifs ...

OK, donc il suffit d'attendre la mise à jour du navigateur de mon mobile préféré pour lancer mon application "web 2.0" basé sur XYZ.js avec plein de plugins et qui en jette un max ?

Ce serait aller un peu vite... les ressources mémoire, bande passante et autres spécificités de l'Internet mobile sont peu considérées par les développeurs, peut être un peu trop habitués aux centaines de Mo d'un PC et au GHz de son processeur.

On trouve par exemple les recommandations de Yahoo sur le sujet. Une grande partie du temps de réponse apparent d'une application est imputable à l'ordre de chargement des fichiers qui composent la page web. En regroupant les scripts, images et les CSS, en les ordonnant et en comprenant le chargement d'une page on peu nettement améliorer sa réactivité.

Les premiers à bien mettre en pratique le web mobile occuperont le terrain ! Rien de tel qu'une application qui rame pour jeter le doute sur une technologie.

01 mai 2008

Spring-JS

Après Spring, Spring-MVC, Spring-WebFlow, Spring-batch, Spring-DM, etc, auras t-on bientôt droit à un Spring-JavaScript ?

--> http://jira.springframework.org/browse/SWF-451

En marge du projet Spring-WebFlow (dans la version 2.0), une couche d'abstraction semble développée pour permettre un accès aux librairies JS (Dojo et Ext pour l'instant) selon une logique "à la Spring".

"

The factoring out of a Javascript abstraction layer called "Spring Javascript" from Web Flow's JSF support. Currently, Dojo and Ext based implementations of this layer are provided. Spring.js provides:

  • A common interface for Ajax, regardless of which toolkit is being used under the covers
  • An aspect-oriented-like API for decorating HTML DOM nodes with behaviors, including client-side validation behaviors.
"

Le portage des idées de l'AOP dans le monde HTML/Javascript est intéressant. Après tout, les sélecteurs CSS sont un bon exemple de langage pour définir des "points de coupe".

Je n'ai pas creusé l'investigation plus loin, mais ce serait un très bon point, vu la prolifération de librairies JavaScript comparables sur de nombreux points, mais pas forcément facile d'accès, surtout pour un développeur 100% Java qui n'y connais pas grand chose aux (très nombreux) raffinements de JavaScript.

Plus d'infos sur http://static.springframework.org/spring-webflow/docs/2.0.x/reference/html/ch10.html