Les différentes versions du langage JavaScript

décembre 14, 2008

Cela fait plusieurs fois que je me suis posé la question s’il est correct de parler de différentes versions du langage script. Cette question m’est revenue suite à la visite du site BrowserHawk. Ce site teste les différentes capacités du navigateur web utilisé (détection du navigateur, temps de réponse). Il fournit une version langage JavaScript utilisé par le navigateur.

J’ai fais le test avec 8 navigateurs pour Windows que je considère comme « pertinents » : navigateur complet (pas une simple surcouche), mis à jour régulièrement. Ma liste est donc : Internet Explorer, Firefox, Safari, Flock, Google Chrome, K-Meleon, SeaMonkey et Opera. J’ai pris les dernières versions stables de ces navigateurs. Je suis toujours à la recherche d’autres navigateurs qui respectent les critères décrits précédemment. Voici les résultats obtenus :

Navigateur Version JS selon BrowserHawk
IE 7 1.5
Firefox 3 1.8
Safari 1.5
Flock 1.7
Google Chrome 1.8
K-Meleon 1.5
SeaMonkey 1.5
Opera 1.5

Les résultats montrent que les versions de JavaScript sont relativement récentes. Ils semblent cohérents (même résultat pour SeaMonkey et K-Meleon). Le second test est l’utilisation explicite de la version de Javascript dans une page Html comme ceci :


<script language= "JavaScript1.2">.../...</script>

ou autre manière plus standard (?)


<script type="text/javascript;version=1.2">
.../...
</script>

La seconde version de cette technique, ne fonctionne pas pour 3 navigateurs. Finalement, j’ai un gros doute sur l’interprétation de ce code. Signifie-t-il vraiment que le cette partie de script est interprétée si le navigateur supporte au moins cette version de JavaScript ? Opera ne serait-il pas un peu gros « vantard » ? Les résultats sont en fait très différents de BrowserHawk.

Navigateur BrowserHawk tag Javascript V1 tag Javascript V2
IE 7 1.5 1.3 ?
Firefox 3 1.8 1.8 1.8
Safari 1.5 1.7 ?
Flock 1.7 1.7 1.7
Google Chrome 1.8 1.7 ?
K-Meleon 1.5 1.7 1.7
SeaMonkey 1.5 1.7 1.7
Opera 1.5 2.0 1.5

Une meilleure solution serait de tester la version de JavaScript en utilisant des fonctionnalités spécifiques à chaque version. JavaScript est normalisé en tant que ECMAScript, et le site de la fondation Mozilla donne les correspondances dans le tableau qui suit. Ce qui pose la question des versions intermédiaires qui seraient spécifiées uniquement par Mozilla.

Version de Javascript Version de Firefox Version de ECMA
1.3 ECMA 262 édition2
1.5 1.0 ECMA 262 édition3
1.6 1.5
1.7 2
1.8 3.0
1.9.1 3.1
2.0 ECMA 262 édition4

Sur le site de Mozilla dit MDC « Mozilla Developer Center », on trouve plus ou moins difficilement les différences entre les versions successives JavaScript. Ce qui m’a permis d’écrire un script testant la version courante du JavaScript. Ce script permet de tester les version 1.0, 1.1, 1.2, 1.3, 1.5, 1.6, 1.7, 1.8 et 1.9.1. Ce script donne avec les 8 navigateurs de références.

Navigateur BrowserHawk tag Javascript V1 tag Javascript V2 test fonctionnalités
IE 7 1.5 1.3 ? 1.5
Firefox 3 1.8 1.8 1.8 1.8
Safari 1.5 1.7 ? 1.6
Flock 1.7 1.7 1.7 1.7
Google Chrome 1.8 1.7 ? 1.6
K-Meleon 1.5 1.7 1.7 1.7
SeaMonkey 1.5 1.7 1.7 1.7
Opera 1.5 2.0 1.5 1.6

Pour valider mon script, je l’ai testé avec les différentes version de Rhino. Il s’agit d’une implémentation en Java du moteur de JavaScript de Mozilla. Attention, il n’est pas utilisé dans les navigateurs Web comme Firefox mais est un reste d’un ancien projet abandonné d’un navigateur web en Java. La version Rhino 1.5R5 correspond à la version 1.5 du JavaScript, la version 1.6R7 correspond à la version 1.6 du JavaScript, et enfin 1.7R1 à la version 1.7. Ceci fonctionne correctement avec mon script. Utiliser Rhino pour exécuter du JavaScript est en effet simple. Il suffit d’utiliser la commande qui suit (test.js est mon script de test). Il existe une méthode main dans ce jar.


java -jar js.jar -f test.js

Au final, on voit qu’il existe un flou dans les différentes version du langage JavaScript mais qu’une version 1.3 ou 1.5 semble un compromis acceptable pour l’instant. Notons bien ici que je parle du coeur du langage et non de l’implémentation du DOM, l’accès aux éléments d’une page Web.

Voici le fichier test.js

function testVersion() {
var myArray = ['a', 'b', 'a', 'b', 'a'];
var res="";
var myNumber=2489.8237
var myString="eer";

//version 1.0
var version1_0=0;
if(Date.parse)
version1_0= version1_0+1;

res=res+"version 1.0 : "+version1_0+"/1 \n";

//version 1.1
var version1_1=0;
if(myArray.join)
version1_1= version1_1+1;

if(myArray.toString)
version1_1= version1_1+1;

if(myArray.reverse)
version1_1= version1_1+1;

if(myArray.sort)
version1_1= version1_1+1;

res=res+"version 1.1 : "+version1_1+"/4 \n";

//version 1.2
var version1_2=0;
if(myArray.concat)
version1_2= version1_2+1;

if(myArray.slice)
version1_2= version1_2+1;

if(myArray.pop)
version1_2= version1_2+1;

if(myArray.push)
version1_2= version1_2+1;

if(myArray.shift)
version1_2= version1_2+1;

if(myArray.splice)
version1_2= version1_2+1;

if(myArray.unshift)
version1_2= version1_2+1;

res=res+"version 1.2 : "+version1_2+"/7 \n";

//version 1.3
var version1_3=0;
if(myArray.push) {
var myArray2 = ['a', 'b', 'a', 'b', 'a'];
//V1.3 push retourne la taille du tableau.
i=myArray2.push('e','r');
if(i==7)
version1_3= version1_3+1;
}

if(myArray.splice) {
var myArray2 = ['a', 'b', 'a', 'b', 'a'];
myArray3=myArray2.splice(1,3,'z');
if(myArray3.length==3);
version1_3= version1_3+1;
}

//Boolean(new Boolean(false)) return false = 1.2 or -
//return true 1.3 or +
if(Boolean(new Boolean(false)))
version1_3= version1_3+1;

res=res+"version 1.3 : "+version1_3+"/3 \n";

//version 1.5
var version1_5=0;
if(myNumber.toFixed)
version1_5= version1_5+1;

if(myNumber.toExponential)
version1_5= version1_5+1;

if(myNumber.toPrecision)
version1_5= version1_5+1;

res=res+"version 1.5 : "+version1_5+"/3 \n";

//version 1.6
var version1_6=0;
if(myArray.indexOf)
version1_6= version1_6+1;

if(myArray.lastIndexOf)
version1_6= version1_6+1;

if(myArray.filter)
version1_6= version1_6+1;

if(myArray.forEach)
version1_6= version1_6+1;

if(myArray.every)
version1_6= version1_6+1;

if(myArray.map)
version1_6= version1_6+1;

if(myArray.some)
version1_6= version1_6+1;

res=res+"version 1.6 : "+version1_6+"/7 \n";

//version 1.7
var version1_7=0;
if(this.Iterator)
version1_7= version1_7+1;

res=res+"version 1.7 : "+version1_7+"/1 \n";

//version 1.8
var version1_8=0;
if(myArray.reduce)
version1_8= version1_8+1;

if(myArray.reduceRight)
version1_8= version1_8+1;

res=res+"version 1.8 : "+version1_8+"/2 \n";

//version 1.9.1
var version1_9_1=0;
if(myString.trim)
version1_9_1= version1_9_1+1;

if(myString.trimLeft)
version1_9_1= version1_9_1+1;

if(myString.trimRight)
version1_9_1= version1_9_1+1;

if(Object.getPrototypeOf)
version1_9_1= version1_9_1+1;

res=res+"version 1.9.1 : "+version1_9_1+"/4 \n";

print(res);

if(version1_9_1==4)
return "1.9.1";
else if(version1_8==2)
return "1.8";
else if(version1_7==1)
return "1.7";
else if(version1_6==7)
return "1.6";
else if(version1_5==3)
return "1.5";
else if(version1_3==3)
return "1.3";
else if(version1_2==7)
return "1.2";
else if(version1_1==4)
return "1.1";
else if(version1_0==1)
return "1.0";
else
return "inconnue";

}
testVersion();

Selenium RC (Remote Control)

novembre 11, 2008

Selenium RC fait partie d’un ensemble d’outils de test des applications web. Parmi ces outils, il existe un outil particulièrement intéressant Selenium IDE.

Ce dernier est un plugin pour Firefox permettant d’enregistrer et de lancer des scripts de test des applications web. Le langage utilisé par défaut est propriétaire, exportable au format HTML. Mais ce plugin peut servir avantageusement de « recorder » pour la version Java. En effet, il suffit d’aller dans le menu de Selenium IDE « option\format » est de choisir le langage Java. En effet, il est parfois au début très difficile de passer du langage de commande au langage Java.

Il est possible d’écrire les tests avec Selenium à l’aide du langage Java. Un framework de test comme JUnit permet d’organiser ces tests. Au début, j’ai été tenté d’utiliser un autre framework de test que JUnit3 (JUnit4). Mais finalement le Selenium RC est une librairie de test intimement liée à JUnit3. Il est préférable de suivre le choix des concepteurs. La classe SeleneseTestCase étend la classe TestCase de JUnit. Elle contient une variable selenium de type Selenium initialisée lors de la méthode setup. Cette variable représente le navigateur web.

La classe SeleneseTestCase fournit des assertions supplémentaires commençant par verify comme verifyEquals. Quelle est la différence avec le assertEquals de TestCase ? En fait, ces méthodes font échouer le test si une assertion n’est pas respectée lors du tearDown, donc sans arrêter le script de test. Attention, ceci est « anti test unitaire », mais reste acceptable ici. En effet les tests des applications web ne sont pas en soit des tests unitaires, mais des tests de plus haut niveau.

Selenium RC se base sur un « serveur » ou un « proxy applicatif ». Pour démarrer ce serveur, le plus simple est d’utiliser le jar selenium-server*.jar, avec la commande « java -jar selenium-server.jar ». Le serveur démarre par défaut sur le port 4444. Il faut éviter de le changer car il s’agit du port qu’utilise la classe SeleneseTestCase. Dans un autre article, je décrirai comment le démarrer de manière programmatique.

Le code du test simpliste de démonstration avec le moteur de recherche Google peut être le suivant:


package com.petitteckel.seleniumdemo;

import com.thoughtworks.selenium.SeleneseTestCase;

public class GoogleTest extends SeleneseTestCase {


 public void setUp() throws Exception {
  //setUp("http://www.google.fr/", "*custom E:\\program\\mozilla.org\\SeaMonkey\\seamonkey.exe");
  setUp("http://www.google.fr/", "*iexplore");
 }


 public void testGoogle() {
  selenium.open("http://www.google.fr");
  verifyEquals(selenium.getTitle(),"Google");
  selenium.type("q", "Selenium");
  selenium.click("btnG");
  selenium.waitForPageToLoad("5000");
  verifyEquals(selenium.getTitle(),"Selenium - Recherche Google");
 }
}

La chaîne de caractères « *iexplore » représente le type de navigateur à utiliser. En effet Selenium RC pour effectuer les tests pilote les navigateurs existants. Il a donc besoin de la présence de ces logiciels. Cela pose des contraintes, par contre a l’avantage d’être fidèle à ces navigateurs. Au niveau des variables prédéfinies, il en existe 11 correspondant à des navigateurs ou des configurations de navigateurs, *iexplore pour Internet Explorer, *firefox pour Firefox, *opera pour Opera. Pour voir la liste de ces variables, il suffit de mettre *nimportquoi au niveau de cette variable et la console du serveur va la refuser et afficher la liste des variables possibles. L’utilisation de ces variables devrait permettre l’utilisation des navigateurs sans les reconfigurer, dans la pratique cela ne marche pas très bien, voire pas du tout. La solution de secours est d’utiliser la chaîne *custom.

Il faut dans ce cas faire suivre *custom du chemin exact du navigateur. Au niveau du navigateur, il faut préciser que le proxy est localhost port 4444. Cela fonctionne avec tous les navigateurs installés sur mon poste Windows (de Flock à Safari en passant par Google Chrome). Mais cela risque de poser un problème si la connexion vers l’application testée passe également par un proxy.

Enfin, il est possible d’utiliser Maven, pour la gestion des dépendances dans le projet Java. Je mets dans l’exemple plus bas les dépendances pour la version 1.0-beta-1 (la dernière). Par défaut, le jar junit3.8.1.jar est mis dans le projet. Ceci confirme bien ce que j’ai expliqué un peu avant.


 <dependency>
  <groupId>org.openqa.selenium.client-drivers</groupId>
  <artifactId>selenium-java-client-driver</artifactId>
  <version>1.0-beta-1</version>
 </dependency>
 <dependency>
  <groupId>org.openqa.selenium.core</groupId>
  <artifactId>selenium-core</artifactId>
  <version>1.0-beta-1</version>
 </dependency>

Au final, je trouve que Selenium RC est un outil intéressant mais pas encore stabilisé, donc difficile à généraliser au niveau d’une entreprise.

L’outil d’automatisation Maven2

novembre 8, 2008

Maven est un outil dont la notoriété et l’utilisation augmente dans le monde Java. Son utilisation croit également dans le cadre de l’entreprise. D’autre part, son utilisation se répand largement dans les projets libres. Il facilite largement la tâche de recompiler un projet libre à partir du code source. Je tenterai ici d’expliquer pourquoi.

Il s’agit notamment d’un outil d’automatisation des tâches, même si ce point de vue est un peu réducteur. Il remplace avantageusement Ant pour la partie automatisation. Dans cette présentation, je me limite à Maven2. En effet, Maven1 était un Ant un peu amélioré sans intérêt réel maintenant.

Maven comme Ant permettent d’automatiser les tâches dans un projet Java, comme la compilation, la génération d’archive, de rapport. Dans Ant, on définit certaines tâches, cela ressemble un peu à de la programmation. C’est donc bien adapté à l’état d’esprit d’un développeur. Mais finalement, on a l’impression redéfinir la roue à chaque fois et les scripts Ant peuvent devenir très longs, peu normalisés et difficiles à comprendre par une personne étrangère à l’équipe projet. Quant à Maven, il se base sur un principe complètement différent de Maven. On ne déclare pas de tâches, elles sont prédéfinies. C’est assez logique. Un projet Java doit être compiler, il devrait être testé, il doit permettre la création d’une archive comme un jar ou un war pour être utilisé facilement par d’autres projets. Donc la commande « mvn test » exécute les tests unitaires, « mvn package » génère l’archive associée au projet, et ceci pour tous les projets utilisant Maven. Il est possible de générer avec Maven, les rapports associés aux outils de qualité comme checkstyle et cobertura.

Comment fonctionne alors ce magique outil Maven ? Le développeur définit dans le fichier pom.xml la structure du projet. Je ne déclare pas les actions à effectuer sur le projet mais comment est structuré le projet. Cette approche déclarative n’est pas forcément la plus proche de l’état d’esprit du développeur mais est ici beaucoup plus efficace. Un autre point diminue fortement la taille du fichier pom.xml, Maven se base sur des conventions. Le code source se trouve par défaut dans le répertoire src/main/java. Il est toujours possible de le placer ailleurs mais finalement il est mieux de suivre les conventions. Le seul cas où il reste utile de surcharger les conventions est lorsqu’on reprend d’anciens projets archivés sous CVS. Le déplacement d’un fichier avec CVS fait perdre l’historique.

Maven gère également les dépendances entre projets avec les versions. Un projet java classique va utiliser le framework de test Junit (version 3 ou 4), la librairie log4j pour la gestion des traces techniques. On déclare explicitement les dépendances et leurs portées (test, compile, runtime). Ceci est sans doute une réponse provisoire au grand désordre qu’est la non gestion des dépendances dans le monde Java (et je suis très poli ici : c’est le vrai B***).

Il demeure cependant quelques problèmes lors de l’utilisation de Maven. Le premier est le manque d’intégration dans Eclipse. Ce problème était important il y a quelques temps. Maintenant, il existe deux plugins m2eclipse et q4e. J’utilise le premier dans mon activité professionnelle, ceci de plus en plus. Le second q4e est un projet Google. Il apparaît plus ambitieux que m2. Il propose notamment une vue graphique des dépendances. Maintenant, l’installation par le site update ne fonctionne pas. Je ne le conseille pas un premier temps et je vous propose m2.

Les plugins ne font pas tout. Il existe un manque dans Eclipse au niveau de la hiérarchie des projets. Tous les projets Eclipse sont au même niveau. Tandis que Maven autorise des hiérarchies de projets. En fait ceci est imposé par Maven du fait qu’un projet Maven correspond à un seul artefact (pas deux ou plusieurs). Ceci risque d’engendrer un nombre important de projets Eclipse. Notons qu’Eclipse n’a pas de notion de portée des dépendances. Donc si vous utiliser Junit, une librairie Junit*.jar apparaît dans la liste des dépendances alors qu’avec Maven on peut indiquer que cette dépendance ne concerne que la partie des tests, et non l’utilisation de l’archive dans un autre projet.

Autre point délicat, je découvre régulièrement des petits bugs dans les plugins Maven de métriques et de qualité du code.

Un nom de domaine pour la Flandre ?

novembre 1, 2008

Le ministre-président Kris Peeters veut créer un nom de domaine de premier niveau (TLD pour Top Level Domain) pour la Flandre. Un TLD est une extension comme le .be pour la Belgique ou le très courant .com qui apparaît dans les applications de l’internet comme l’adresse web ou l’adresse mail. Pour un pays ont parle de ccTLD (country code TLD) et pour un nom de domaine ouvert à tous de gTLD (generic). Un troisième groupe forme les sTLD pour les noms de domaines limités à une communauté, dits « commandités »

L’ICANN l’association qui gère les noms de premier niveau avait une politique très prudente de ces noms. Les pays ont d’office un nom de premier niveau sur deux lettres suivant la norme ISO 3166-1 comme le .be ou le .fr. Mais, il n’y avait rien pour les subdivisions des pays ou les grandes métropoles…

Mais en 2005, l’ICANN a autorisé le sTLD .cat pour la communauté catalane (langue et culture, par pour la région espagnole). Suite à cette décision sans doute un peu hasardeuse, de nombreuses régions se sont mises à rêver de leur propre nom de domaine de premier niveau. Une association milite pour un .bzh pour la Bretagne. D’autres initiatives font la promotion d’un .sco pour l’Ecosse et d’un cym pour le Pays de Galles. Les peuples celtiques abusent-ils de l’alcool ?

Cette année, l’ICANN a annoncé une certaine libéralisation des noms de domaine de premier niveau pour un démarrage effectif en 2009. Juste un petit détail supplémentaire, le budget est estimé à 100 000 euros. En fait d’autres sources parlent d’une somme un peu plus élevée : 200 000 Dollars américains.

Quel est vraiment l’intérêt d’un tel nom ? Les noms de domaine génériques (ouvert à tous) lancé vers 2001 comme le .biz ou le .info ont eu des succès mitigés. Des sTLD comme le .mobi ou le .tel finissent par être ouvert à tous. Je pense que pour les grandes régions cette idée n’est pas si farfelue qu’elle n’y paraît. Maintenant, quel nom de domaine pour ma région ? Le .vl est libre mais ce nom n’est pas autorisé par le règlement de l’ICANN (la Flandre n’est pas un état indépendant). Les propositions sont .vla .vln .vlaanderen .fla…

Il est beau mon petit lion...

Il est beau mon petit lion...

Les outils de test commerciaux iMacros et eValid

octobre 15, 2008

Concernant les tests des applications web, je me suis posé la question s’il est possible de tester des applets. Cette problématique pourrait être généralisée aux autres technologies comme Flash Silverlight. Les outils libres ne semblent pas répondre à cette question. Je me suis tourné vers des outils commerciaux, iMacros et eValid.

IMacros existe sous forme de plugin pour navigateur web en freeware, également pour une utilisation commerciale. Ce plugin existe pour les navigateurs Firefox et Internet Explorer. Les tests sont écrits avec un langage de script spécifique. Il existe un enregistreur. Le site d’Iopus déclare que iMacros supporte les technologies Flash, Flex, Java, Silverlight. Dans la pratique le freeware ne semble pas fonctionner correctement, et le principe semble de repérer au pixel près la position du curseur. Est-ce réellement portable.

Le second outil qui peut répondre à ce problème est eValid. Je n’ai pas pu réellement le tester.

Webdriver nouvelle version (524)

septembre 25, 2008

La version de Webdriver 524 est sortie le 18/09/2008. Pour rappel, Webdriver est un outils de test des applications web se basant sur le langage Java. Il s’agit toujours d’une version « alpha ». Cependant ses principes sont intéressants. Ce projet mérite donc d’être suivi attentivement. En plus, ce projet est soutenu par Google, devenue une sociétés informatiques parmi les plus puissantes.

Il s’agit en fait d’une interface simple. C’est à dire une API assez simple avec très peu de classes. Plusieurs implémentations existent, il est possible d’écrire de nouvelle implémentation. En fait quatre implémentations sont proposées.

  • Safari (mais pour Mac OS uniquement)
  • Firefox
  • htmlUnit (basé sur la version 2.2 d’HtmlUnit)
  • jobbie (Internet Explorer)

Dans les versions précédentes sous Vista, seules les implémentations Firefox et HtmlUnit fonctionnaient correctement. Dans cette nouvelle version, la version pour IE fonctionne. Voici quelques actions à effectuer après l’installation. Pour Firefox, il faut définir un profil webDriver. Utilisez en mode commande « firefox -p ». Pour la version Internet Explorer sous Vista, il faut ajouter les domaines utilisés lors des tests dans les sites de confiance. Avec Internet Explorer 7, utiliser le menu Outils\Options Internet, aller à l’onglet Sécurité et changer la liste des sites de confiance.

Au final, j’ai commencé une méthode d’évaluation des outils de test des applications web. Il s’agit d’une série de tests simples à écrire pour évaluer une application écrite avec Strust version 1.4. Pour l’instant le nombre de tests est de 4, mais je compte l’augmenter progressivement. Au final, les versions HtmlUnit et Firefox réussissent l’évaluation. Par contre, la version Internet Explorer échoue sur un test.

Implémentation Fonctionne sous Visa Evaluation
Safari Non (Mac OS X uniquement) N/A
Firefox Oui 4/4
HtmlUnit Oui 4/4
Jobbie (Internet Explorer) Oui 3/4

Comparaison des différents navigateurs Web basée sur les tests Acid

septembre 20, 2008

Une piste de comparaison des navigateurs web est le respect des standards Web. Plusieurs tests ont été mis en place pour montrer le respect ou non par les navigateurs web des standard du web. Ceci évite une « balkanisation » du web. Le test Acid1 été mis en place en 1998 par Tod Fahrner et ne concerne que les CSS. Il n’a qu’un intérêt historique. Les deux suivants Acid2 et Acid3 dépendent du WASP (Web Standards Project). Le test Acid2 date de 2005. Il ne concerne que les CSS1 et CSS2. Son résultat est purement visuel. Le dernier Acid3 concerne un spectre plus large de technologies DOM level2, JavaScript, CSS3, SVG… Il est très récents 2008. Le résultat est une note sur 100. Il s’agit de 100 tests de base. Il est possible de voir les tests ayant échoué. Enfin, il existe un site qui regroupe l’ensemble des test acid.

La liste suivante se compose des principaux navigateurs actifs disponibles pour Windows, en dehors des surcouches pour IE (comme CrazyBrowser et Maxthon). Les navigateurs abandonnés comme Netscape n’y sont pas présents. Pour l’instant cette liste compte 8 membres.

La comparaison a été faite avec les dernières versions stables des navigateurs sous Windows Vista. Il est remarquable que les deux grands sont loin d’être les premiers. Firefox passe le test Acid2 depuis sa version 3. IE est toujours bon dernier. Les équipes de Microsoft n’ont jamais officiellement mis ces tests Acid en priorité. Les navigateurs basé sur le moteur de rendu de Firefox 2, K Meleon, Flock et SeaMonkey obtiennent en gros le même résultat. Enfin, aucun navigateur obtient 100 au test Acid3.

Voici les résultats détaillés :

Navigateur Version Test acid 2 Test acid 3
Opera 9.52 Oui 84/100
Google Chrome 0.2.149.29 Oui 78/100
Safari pour Windows 3.1.2 Oui 75/100
Firefox3 3.01 Oui 71/100
K Meleon 1.5 Non 53/100
Flock 1.2.5 Non 53/100
SeaMonkey 1.1.11 Non 52/100
IE 7 Non 12/100

Le test de performance JavaScript SunSpider

septembre 18, 2008

SunSpider est un test de performance du moteur de JavaScript. Ce test a été écrit par l’équipe de WebKit le moteur de rendu HTML présent dans les navigateurs sous Mac OS, comme Safari. Ce benchmark exécute 5 fois une série de tests et fournit une moyenne.

Le JavaScript est assez important pour les utilisateurs des applications web. En effet, le type de code est exécuté sur le client et non le serveur. L’importance de ce langage s’est accrue avec le Web 2.0. Cependant, la performance du moteur de JavaScript n’est qu’un élément dans le performance globale du navigateur web. Cela ne présume pas de la performance globale du navigateur.

Les résultats suivants ont été obtenus sur Windows Vista avec les navigateurs actifs, les plus courants dans leurs dernières versions stables. Google Chrome avec son tout nouveau moteur V8 obtient un résultat remarquable. Par contre celui d’Internet Explorer 7 est médiocre, en effet le moteur de JavaScript de ce navigateur est de conception ancienne et devrait être remplacé dans la version 8.

Navigateur Version Résultat
Google Chrome 0.2.149.29 3 301 ms
Firefox 3.01 5 558 ms
Safari 3.1.2 7 019 ms
Opera 9.52 7 931
K Melon 1.5 15 321 ms
SeaMonkey 1.1.11 21 422 ms
Flock 1.2.5 23 214 ms
IE 7 58 033 ms

Une petite fonctionnalité de Google Chrome

septembre 14, 2008

J’ai fait découvert une petite fonctionnalité de Google Chrome. Souvent, je tente de débugger du code Javascript avec une série de boite de dialogue « alert ». Cette méthode est loin d’être parfaite…
Google Chrome propose à la seconde boite de dialogue d’empêcher l’affichage des boites de dialogue suivantes.

Les autres navigateurs courants ne possède pas cette fonctionnalité. Une exception notable est Opera qui propose d’arrêter l’exécution des scripts dans la page, ce qui est un peu plus brutal que dans le cas de Google Chrome.

arret des boites de dialogue javascript

arret des boites de dialogue javascript

arrêt des scripts dans Opera

arrêt des scripts dans Opera

Le nouveau navigateur Google Chrome

septembre 8, 2008

Google a sorti son navigateur web Google Chrome. Cette sortie a largement été commentée du fait de la place stratégique du navigateur web. Google Chrome est un logiciel libre, de licence BSD. Il s’appuie sur WebKit également sous BSD. Le projet est hébergé sur le site code.google.com.

Un moteur de Javascript a été développé spécifiquement pour ce navigateur, V8. Ce projet est également sur le site code.google.com. Autre point, le support des applets nécessite apparemment Java 6 update 10.

Enfin, ce navigateur apparaît très respectueux des standard web. Je l’ai testé sous Windows. Il réussit largement le test acid2. Il obtient un score de 79/100 au test acid3. Ce qui est un résultat excellent pour une navigateur sous Windows.