Internet Explorer 9 : de l’innovation à tous les étages

Nous vous en avions déjà parlé à travers ce précédent billet lors de sa 1ère présentation à la PDC09 de Novembre 2009. Internet Explorer 9 a d’abord été présenté à nouveau dans une version plus récente nommée PP1 (Platform Preview 1) lors du MIX10 qui s’est déroulé à Las Vegas en Mars dernier puis mis à jour le 5 mai vers PP2 (Platform Preview 2) et téléchargeable ici. Vous pouvez donc dors et déjà télécharger cette pré-version technologique qui s’installe à côté de votre navigateur existant et tester ce que nous allons voir en détail ci-dessous. A noter que cette pré-version s’adresse plutôt à un public de développeurs ou d’experts du web souhaitant commencer à mettre à l’épreuve notre nouveau moteur dans la mesure où il est limité au niveau interface utilisateur. Il n’a pour l’instant donc pas vocation à remplacer un navigateur existant mais est plus là pour vous laisser jouer avec ce qu’il y aura sous le capot de notre futur navigateur. Nous publierons ensuite sous un rythme de 8 à 10 semaine de nouvelles pré-versions jusqu’à une 1ère Beta puis une RTM.

Au sommaire de cet article :

- Support de HTML5, CSS3 et SVG 1.1… le tout accéléré par le GPU !
- Etude d’un cas SVG pour montrer l’importance des tests
- Un nouveau moteur JavaScript tirant partie des processeurs multi-cœurs
- Les balises <video> et <audio> supportées et accélérées
- Le GPU aussi pour le rendu HTML où vous retrouverez un comparatif de performance entre IE8/Chrome 4.1/Safari 4.0.5/Firefox 3.6 et IE9 PP1 (Platform Preview 1)
- Conclusion où je donnerais mon rapide point de vue sur HTML5 face à Silverlight

Support de HTML5, CSS3 et SVG 1.1… le tout accéléré par le GPU !

Avec Internet Explorer 8, nous avions énormément travaillé sur le support des standards HTML 4.01 et CSS 2.1 à travers notamment une soumission de 7200 tests supplémentaires au près du W3C pour clarifier et affiner ce que devait être un support correct de ces standards. Nous considérons en effet que la norme actuelle du développement web repose sur ces spécifications. Du coup, aujourd’hui, IE8 doit certainement être le navigateur le plus respectueux des standards CSS 2.1 contrairement à ce que beaucoup peuvent penser (gardant en tête IE6 conçu dans les années 2000… il y a donc 10 ans !). Cependant, l’avenir plus ou moins proche passera forcément (entre autres) au travers des nouvelles versions que sont HTML 5/CSS 3 et SVG 1.1. Nous allons donc bien entendu effectuer le même travail de rigueur sur l’implémentation de ces nouveaux standards et surtout participer activement à la mise en place de jeux de tests et de clarification avec le W3C comme nous l’avions fait avec IE8 et CSS 2.1. En effet, HTML5 et CSS3 sont des spécifications à l’état de “working draft” (nous sommes aujourd’hui à la version de Mars 2010). Cela implique qu’il reste encore énormément de parties en évolutions constantes et d’autres encore bien floues. Certaines sont déjà relativement claires et figées, nous allons donc pouvoir facilement les implémenter sans trop de risques comme l’ont déjà fait certains de nos concurrents. Cependant, il est important de noter que de l’aveux même des membres du W3C, le chemin reste long pour un accouchement complet du HTML5. Certains l’estiment même à presque 10 ans ! Pour des raisons assez simples en fait. Tout d’abord, les spécifications ne sont toujours pas terminées. Une fois que ce sera le cas (espérons avant la fin de l’année), il faudra concevoir des énormes batteries de tests (on parle de 60 000) pour mettre à l’épreuve ces spécifications pour garantir une implémentation harmonieuse entre les différents navigateurs. Ensuite, il faudra que ces mêmes navigateurs s’emparent d’une part de marché significative (majoritaire donc) pour que l’on puisse envisager sereinement d’exploiter ces nouvelles technologies au sein de nos sites/applications web.

Aujourd’hui, on voit pourtant malgré tout une compagne marketing soutenue autour du test ACID3 par exemple. Or ce test, bien qu’intéressant, ne représente qu’un sous-ensemble très spécifique des futurs standards qui sont eux-mêmes non encore terminés ! Ainsi, ce n’est pas parce que l’on passe le test ACID3 à 100% que l’on implémente pour autant parfaitement les standards. C’est d’ailleurs exactement la même chose pour le test ACID2. Alors que Firefox passait depuis longtemps à 100% ce test (là où il nous a fallu attendre IE8 pour le passer de notre côté…), à travers nos 7200 tests, nous nous sommes malgré tout aperçu que Firefox implémentait toujours mal certaines parties de CSS 2.1 lorsque IE8 est sorti. Tout cela pour dire qu’il faut faire attention à la communication autour de ces tests. Autant de notre part… que de celle de nos concurrents ! ;-) Mais bon, ces tests de suites ont l’avantage de faire avancer le schmilblick comme on dit par chez nous.

Au sujet du test ACID3, la version d’IE9 PP2 que vous pouvez actuellement télécharger obtient un score de 67/100 (soit une augmentation de 35 points par rapport à Novembre dernier). Alors je vois souvent certaines mauvaises langues écrire dans des forums : “Mais comment se fait-il que Microsoft n’arrive toujours pas à 100% ?!? C’est pas possible, ce sont les seuls à ne pas y arriver !”. Pour une raison simple : nous ne travaillons pas spécifiquement à l’amélioration du code d’IE9 pour augmenter le score du test ACID3. Pour le faire, il suffirait d’implémenter uniquement les spécifications testées par ACID3 et nous serions à 100%. Mais notre objectif est plus ambitieux que cela. Nous souhaitons implémenter au mieux les spécifications HTML5, CSS3 et SVG 1.1. Si c’est le cas, nous passerons alors forcément à 100% le test ACID3 puisqu’il est censé en représenter un sous-ensemble. Une stratégie peut-être à contre courant de certains autres mais qui nous l’espérons sera payante à terme.

Si vous souhaitez rentrer dans le détail, vous pouvez retrouver la liste actuelle de ce que nous avons implémenté pour HTML5, CSS3 et SVG dans IE9 ici :

- Internet Explorer Platform Preview Guide for Developers : http://msdn.microsoft.com/en-us/ie/ff468705.aspx

En parallèle, nous avons commencé à soumettre certains tests nous aussi pour mettre à l’épreuve les navigateurs sur le respect des spécifications. Vous pouvez retrouver des informations à ce sujet ici : http://samples.msdn.microsoft.com/ietestcenter/ 

Par exemple, voici un état actuel du passage de ces tests entre les différents navigateurs majeurs du marché :

Alors comme je vous l’ai dit plus haut, même si IE9 semble mieux s’en tirer sur cette batterie spécifique de tests, ne vous formalisez pas forcément sur ces résultats. Ce qu’il est important de retenir c’est qu’il reste du travail sur la clarification des standards pour que tous les navigateurs puissent travailler sereinement sur leur implémentation. En effet, une fois que tout sera clair, tout le monde pourra implémenter les standards et, espérons-le, le calvaire des développeurs web sera enfin terminé. Lorsque ce sera le cas, le débat se décalera alors naturellement du test ACID3 et consorts vers des questions selon moi plus intéressantes : les qualités intrinsèques du navigateur tant au niveau de ses performances que des innovations qu’il apporte.

Etude d’un cas SVG pour montrer l’importance des tests

Comme je l’ai dit précédemment, mettre au point une spécification permettant d’implémenter de manière interopérable des fonctionnalités telles que SVG n’est pas chose évidente.

Par exemple, Patrick Dengler, un des membres du groupe de travail SVG et Senior Program Manager à Microsoft, travaille de manière très étroite avec le groupe de travail SVG pour les aider à définir le futur de SVG et de s’assurer que notre implémentation soit interopérable. Bien que la 1ère édition des spécifications ait reçue le statut de “recommandation” il y a quelques années, ces mêmes spécifications ne sont pas toujours très claires pour autant. Du coup, le comportement des implémentations SVG dans les navigateurs web principaux varient souvent de l’un à l’autre. Notre objectif au sein du W3C est de rendre la vie des développeur meilleure à travers une garantie d’interopérabilité. Ainsi pour les portions de spécifications que nous implémentons, nous essayons d’adhérer au plus proche des specs. Dans certaines situations, notre décision fut conduite par le comportement des autres navigateurs et par les directions prises par le futur de SVG.

Prenons un exemple. Quel comportement avoir lorsqu’un élément <rect> dispose de valeurs négatives à la fois pour rx et ry ? La situation n’est pas très claire dans les spécifications 1.1. Une note dans la page suggère un comportement alors que le guide de gestion des erreurs en suggère un autre.

Observons ainsi l’interprétation du SVG suivant :

 <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100">
   <rect x="10" y="10" width="50" height="80" rx="-10" ry="-10" fill="red"/>
</svg>

Au sein de d’Opéra, Firefox et Chrome :

Alors qui a raison ? Presto (Opera) traite les valeurs négatives rx et ry comme 0, Gecko (Firefox) ne rend tout simplement pas le rectangle à l’écran et Webkit (Chrome, Safari) utilise les valeurs négatives spécifiées pour rx et ry. Tous les navigateurs principaux proposent un comportement différent. C’est le résultat d’une légère imprécision dans les specs 1.1. En regardant un peu plus loin dans les spécifications SVG Tiny 1.2, on s’aperçoit que ces dernières clarifient le comportement en indiquant que les valeurs négatives ne doivent pas être considérées comme une erreur mais ne sont tout simplement pas supportées. C’est le comportement que nous avons choisi d’implémenter avec IE9.

Cela vous montre bien l’intérêt des jeux de tests unitaires (bien au delà des suites ACID donc) permettant de garantir une bonne interopérabilité des standards indispensable au succès des futures applications Web qui se reposeront dessus.

Un nouveau moteur JavaScript tirant partie des processeurs multi-cœurs

JavaScript est devenu omniprésent dans les applications Web modernes notamment à travers l’utilisation de librairies Ajax ou jQuery par exemple. IE 8 avait amélioré de manière significative les performances de l’interpréteur JavaScript par rapport aux précédentes versions (IE6 et IE7) mais restait malgré tout derrière les concurrents en performance pure.

IE9 va tirer mieux partie des nouvelles architectures multi-cœurs de nos processeurs. Tout d’abord, lorsque la page commencera à se charger, l’interpréteur “classique” de script démarra sur le 1er cœur. Déjà, ce nouvel interpréteur a été réécrit pour être plus rapide que celui d’IE8. En parallèle, IE9 utilisera un des autres cœurs disponible pour compiler en tâche de fond en code natif le JavaScript contenu dans la page. Dès que cette compilation sera terminée, IE9 utilisera le code natif en lieu et place du code interprété pour des performances nettement supérieures. Le nom de code de ce nouveau moteur est Chakra.

Grâce à cette technologie, la pré-version d’IE9 PP2 que vous pouvez télécharger est ainsi déjà plus rapide que le moteur JavaScript de Firefox 3.6 et 3.7 Alpha 5. Il reste actuellement un peu derrière ceux de Safari 4/Chrome 4 et Opera 10.52 actuellement considéré comme le plus rapide dans ce domaine. Voici le résultat de ces tests sur le WebKit.org’s SunSpider v0.9.1 Benchmark (version Avril 2010 conçu par Apple) :

Tests effectués sur la machine suivante : Dell OptiPlex, Microsoft Windows 7 Enterprise 6.1.7600, 64-bit, 3.0GHz Intel Core 2 Duo, 4GB RAM, Intel Integrated Video

Il est ainsi intéressant de noter 2 choses :

1 – Les navigateurs se tiennent maintenant tous dans un mouchoir de poche, les différences entre eux se chiffrant désormais à quelques centaines millisecondes. En résumé, la perception visible des différences entre les moteurs JavaScript va devenir nulle pour l’expérience utilisateur sur la quasi-totalité des sites.

2 – Nous sommes ici qu’en présence d’une version Alpha de notre moteur ! Espérons que la version finale sera en mesure de reprendre enfin la place de leader sur ce sujet.

Cependant, de la même manière ou je vous disais de faire attention aux résultats du test ACID3, faites également attention aux significations de ce benchmark. Il ne teste que certaines parties spécifiques du moteur (concaténation de chaînes, conversion de types, etc.). Il existe ainsi d’autres tests pouvant afficher des classements différents en testant d’autres éléments. 

Les balises <video> et <audio> supportées et accélérées

Certainement une des fonctionnalités la plus médiatisée de HTML5 ! De notre côté, nous aurons bien entendu un support de ces nouvelles balises. Pour la partie vidéo, nous avons fait le choix de retenir le codec h264 souvent reconnu comme techniquement meilleur que son concurrent sur cette balise, le codec libre Ogg Theora. Du coup, on se retrouve aujourd’hui avec 2 camps. D’un côté Microsoft, Google (à travers YouTube) et Apple ayant pour l’instant fait le choix du h264 pour la balise vidéo et de l’autre côté, Mozilla, Opera et Google à nouveau (Chrome supportant les 2) ayant fait le choix du codec libre. Le problème est donc aujourd’hui loin d’être résolu mais on avance malgré tout petit à petit.

Le décodage de la vidéo se fera à travers l’utilisation du GPU de la machine lorsque celui-ci sera disponible. Grâce à cette technologie que l’on qualifie souvent “d’accélération matérielle”, nous avons pu faire ainsi une démonstration intéressante à MIX10 en Mars dernier. Un netbook classique (un modèle de chez HP) était capable de lire 2 vidéos HD en 720p simultanément sous IE9 avec un taux d’utilisation processeur de l’ordre de 30% là où la même machine sous Chrome 4 utilisait 100% du CPU pour 1 seule vidéo HD 720p tout en perdant des images dans le rendu de la vidéo. Si vous souhaitez voir cette démonstration en vidéo, vous pouvez la voir ici : http://live.visitmix.com/MIX10/Sessions/KEY02 vers le marqueur temporel 26min30.

On connait aujourd’hui justement le succès de ce type de petite machine nomade. Malheureusement, je vois trop souvent certains utilisateurs déçus car ils n’avaient pas compris que la technologie embarquée dans un netbook était nettement inférieure en terme de performance que dans un laptop classique. Heureusement, les netbook embarquent de plus en plus souvent des GPU suffisamment puissants pour soulager le petit CPU (Atom) dans des tâches spécifiques comme la vidéo. La technologie embarquée dans IE9 est donc clairement intéressante pour ces petites machines ! Pour les autres, à vous la lecture vidéo 1080p plein écran pendant que vous utiliserez votre machine pour faire autre chose. ;-)

Le GPU aussi pour le rendu HTML

A part le décodage de la balise <video>, le GPU sera également utilisé pour globalement accélérer le rendu des pages. En effet, comme je vous en avais déjà parlé dans l’article précédent, le navigateur passe souvent entre 30 et 50% de son temps à gérer le rendu des pages web et leurs mises en page. Il n’y a donc bien plus que le moteur JavaScript à optimiser si l’on souhaite augmenter les performances globales de navigation. On va ainsi analyser le comportement de plusieurs navigateurs sur un test que nous avons développé pour observer comment ils sollicitent les différentes parties matérielles de votre machine. Ce test appelé en anglais Flying Images est l’un des exemples de la suite d’IE9. Vous retrouverez dans cette suite de tests des exemples d’utilisation de SVG également intéressants.

Lorsque vous lancez le test Flying Images sur différent navigateurs, vous verrez ainsi qu’Internet Explorer 9 peut afficher des centaines d’images à pleine vitesse là ou d’autres navigateurs, Internet Explorer 8 inclus, arrivent bien plus vite à saturation complète.

Cette démo technologique, bien qu’elle puisse apparaître de prime abord sans intérêts pour l’utilisateur final, est malgré tout un bon exemple du type d’expérience qui va devenir possible grâce à la technologie d’accélération matérielle embarquée dans IE9. Ce test utilise en effet des balises standards HTML, CSS et du code JavaScript pour animer les images en faisant appel à des méthodes de développement connues. Vous pourrez en effet retrouver ces mêmes méthodes dans de nombreux endroits sur le web, particulièrement au sein de jeux basés sur JavaScript et dans les framework d’animations nécessitant des temps de réponse de l’ordre de 60 images par seconde (60 ips).

Nous avons en effet revu le cœur d’Internet Explorer 9 de manière à ce qu’il utilise l’accélération matérielle. Ainsi le moteur de rendu d’IE9 utilise le GPU pour l’ensemble des graphiques et texte présents dans les pages web. IE9 envoie ainsi les calculs graphiques traditionnellement gérés par le CPU vers un composant plus rapide et plus spécialisé. Tout cela couplé au nouveau moteur JavaScript multi-cœurs, on se rends ainsi compte qu’IE9 tente de tirer au maximum le meilleur de votre machine.

La manière la plus simple de voir l’impact de l’accélération matérielle sur les performances de rendu d’une page comme Flying Images est de comparer l’activité du CPU à celui du GPU à travers les différents navigateurs.

Vous pouvez analyser l’activité CPU et GPU en utilisant le gestionnaire de tâches de Windows, Process Explorer ou votre utilitaire préféré. Cependant, pour une analyse détaillée et affinée, nous vous recommandons d’utiliser les outils de performance de Windows (disponible en téléchargement ici). Ces outils de développement sont fréquemment utilisés pour profiler l’usage des ressources fait par Windows et permet de filtrer l’activité à un niveau de détails processeur. Ils ne sont donc pas à la portée de l’utilisateur lambda mais peuvent être extrêmement pratiques pour un développeur qui souhaite analyser les performances de son application. Les résultats qui suivent ont été réalisés avec ce fameux outil sur un PC vieux de 2 ans : Dell Precision WorkStation (Intel Pentium Dual-Core à 3.0 GHz, 4 Go de mémoire physique, NVIDIA GeForce 8600 GT, 100 Go 7200 tours/min, Windows 7). Les résultats peuvent donc naturellement varier légèrement suivant la configuration utilisée mais les modèles suivant sont représentatifs de ce qu’Internet Explorer 9 pourra apporter à l’expérience utilisateur.

Commençons par revoir les performances du test Flying Images exécuté au sein d’Internet Explorer 8. Le graphique ci-dessous présente l’activité CPU et GPU ainsi que les fréquences de rafraichissement visuelle sur des fenêtres d’une 1/2 seconde une fois que la page complète est chargée et que les animations sont démarrées.

On le voit alors : Internet Explorer 8 a presque complètement utilisé 100% d’un cœur entier (50% d’une machine bi-cœur donc). Il utilise en effet ce cœur pour tenter de faire bouger le plus vite possible les images afin de maintenir éventuellement le rythme des 60 ips. Cependant, bien que certains navigateurs (comme IE8 d’ailleurs) dispose d’une architecture multi-process, le modèle de programmation web fut conçu dans une optique mono-threadée. Ainsi, un processeur multi-cœurs ne peut pas travailler en parallèle sur cette sollicitation. Du coup, même avec un taux de charge très élevé sur le processeur, on peut voir qu’IE8 n’arrive qu’à effectuer un déplacement toutes les 0,221 secondes comme on peut le voir sur le 3ème graphique ci-dessous (barres vertes). Le résultat est donc sans appel : une vitesse d’affichage saccadée à 4,5 ips. Vous observerez également qu’IE8 n’utilise ici pas du tout le GPU dans ce scénario.

Si l’on effectue la même analyse avec Google Chrome 4.1, vous noterez que Chrome utilise lui aussi un cœur complet du CPU et ne fait pas usage non plus du GPU en tentant de maintenir les 60 ips. Chrome n’arrive ainsi qu’à effectuer un déplacement que toutes les 0,238 secondes entrainant ainsi un framerate de 4,2 ips.

IE8 et Chrome 4.1 ont ainsi des résultats quasiment identiques sur ce test avec une fréquence d’affichage de l’ordre de 4 ips. Pourtant le moteur JavaScript de Chrome 4.1 apparait comme nettement plus rapide que celui d’IE8 sur les benchmarks classiques comme le SunSpider. Cependant, le test Flying Images stresse de manière plus globale l’ensemble des sous-systèmes du navigateur. JavaScript est effectivement utilisé pour calculer la nouvelle position des images. Mais il y a également une utilisation de CSS, de la mise en page des images, du moteur de rendu pour les afficher à l’écran, etc. Cela constitue donc un bon exemple tentant de démontrer que les performances d’un navigateur sont liées à des facteurs multidimensionnels qui vont au-delà du simple moteur JavaScript.

Continuons notre analyse avec un autre navigateur reposant sur le moteur Webkit : Apple Safari 4.0.5. Safari utilise lui aussi un cœur complet pour tenter de maintenir la cadence des 60 ips et réussi à faire bouger l’ensemble toutes les 0,191 secondes soit un framerate de 5,2 ips. Ainsi, bien que Chrome et Safari soient basés sur la même souche technologique, Safari est capable de faire bouger l’ensemble de manière 20% plus rapide que Chrome. Cependant, à nouveau, vous observerez que Safari n’utilise toujours pas le GPU pour tenter d’augmenter les performances de rendu.

Passons désormais à Mozilla Firefox 3.6. Vous noterez que comme les autres navigateurs, Firefox utilise toujours qu’un seul des 2 cœurs. Malgré tout, Firefox effectue clairement un meilleur boulot que les navigateurs cités précédemment en réussissant à mettre à jour les images toutes les 0,062 secondes soit un taux de 16,1 ips. C’est clairement meilleur que les autres navigateurs ! Cependant, nous sommes toujours loin de notre objectif stabilisé de 60 ips… Par ailleurs, l’une des techniques que Firefox utilise pour atteindre ce niveau de performance consiste à dégrader la qualité des images pendant la mise à l’échelle alors que les autres navigateurs essaient de maintenir la qualité optimum des images d’origine. C’est effectivement l’un des challenges lorsque vous ne faites pas appel à l’accélération matérielle. Vous êtes forcés d’effectuer des compromis entre la performance et la qualité.

Terminons par lancer cette page au sein d’Internet Explorer 9 Platform Preview 1 (la PP2 n’ayant que légèrement améliorer les performances, je n’ai pas mis à jour le graphique). Vous devriez ainsi voir en observant le graphique ci-dessous que l’accélération matérielle change fondamentalement la donne. La 1ère chose que l’on peut noter est qu’IE9 utilise le GPU ce qui lui permet ainsi d’atteindre ce fameux seuil d’affichage temps réel à 60 ips. Encore plus remarquable, IE9 est capable d’atteindre ce niveau de performance en n’utilisant que 12% du CPU et 15% du GPU.

Tentons de comprendre ce qu’il se passe. Lorsque la page web est chargée, Internet Explorer 9 bénéficie de l’architecture multi-cœurs pour compiler le code JavaScript en code natif. Ensuite, il utilise ce code natif sur chacun des mouvements pour déterminer très rapidement le prochain emplacement de chacune des images puis les anime à travers le processus de mise en page CSS. Pour terminer, IE9 délègue l’affichage des images au GPU qui, grâce à son architecture matérielle plus spécialisée, réussi à mettre à jour l’écran de manière nettement plus efficace. Comme le CPU et le GPU travaillent en parallèle de concert, on peut désormais envisager effectuer davantage de calculs sur le CPU pendant que le GPU s’occupe de gérer l’affichage. Dans cet exemple, comme il n’y a pas grand chose à calculer malgré tout, le CPU reste inutilisé jusqu’à ce que le prochain mouvement d’images soit nécessaire (courbe rouge).

Le plus impressionnant je pense dans ces mesures est de constater que ce test ne stresse en rien les capacités d’Internet Explorer 9. IE9 utilise en effet que 12% du CPU et 15% du GPU sans pour autant effectuer le moindre compris sur la qualité des images. Il reste donc environ 80% des ressources du PC disponibles pour les développeurs web et leur créativité.

Note : à titre de curiosité et pour tenter d’être le plus juste possible, j’ai également testé une version alpha d’une build de Firefox 3.7a3 tentant d’implémenter un rendu au-dessus de Direct2D (technologie utilisée par IE9 pour l’accélération matérielle). J’ai alors suivi cette procédure pour activer l’utilisation de Direct2D. On constate alors un net gain de performance. Il semblerait d’ailleurs que l’on atteigne alors les performances d’IE9 sur ce test spécifique. Je ne sais pas par contre si cette version 3.7a3 corrige les problèmes de dégradation de mise à l’échelle. J’ai également testé la version 10.51 d’Opéra qui affiche quant à lui des performances nettement au-dessus de Firefox 3.6 (avec quelques bugs visuel sur ma machine cependant) tout en restant toujours en dessous d’IE9 sur ma machine et sur ce test.

Conclusion

Il est clair que HTML5 permettra avec son lot de nouvelles fonctionnalités standardisées la création d’une nouvelle génération d’applications aujourd’hui uniquement accessibles à travers des plug-ins propriétaires comme Flash ou Silverlight. Cette nouvelle génération d’applications ne devront pas être limitées par les performances des navigateurs d’aujourd’hui. Implémenter HTML5 correctement implique donc de permettre aux développeurs de créer des applications web qui auront un niveau de performance équivalent aux applications de bureau/clients riches. C’est clairement notre objectif avec Internet Explorer 9 en plus d’un travail de rigueur sur la clarification des spécifications du futur HTML5 à travers la soumission permanente de nouveaux jeux de tests.

J’aimerais également terminé par un rapide point sur la guerre de communication actuelle et parfois stérile entre HTML5 vs Flash ou vs Silverlight. Certains annoncent la fin de ces plug-ins avec l’arrivée de HTML5. Je pense que c’est clairement sous estimer le potentiel de ces technologies et des outillages associés. L’ensemble étant plutôt voué à vivre ensemble de manière harmonieuse. Tout d’abord, comme je vous l’ai expliqué en début d’article, le déploiement d’HTML5 est loin d’arriver de part la nature complexe du travail de standardisation qu’il requiert. Ensuite, HTML5 couvrira effectivement de nouveaux scénarios uniquement couvert jusqu’à présent par Flash ou Silverlight (vidéos embarquées, affichage vectorielle avec SVG, etc.). Mais si l’on prend le cas de Silverlight, ce dernier offre bien plus que cela en terme de frameworks (WCF RIA Services par exemple pour une productivité maximum dans la création d’applications d’entreprise), de langages (.NET avec la présence de LINQ par exemple) et d’outillages (Visual Studio 2010/Expression Blend 4). En effet, rien que du côté de l’outillage, nous n’avons pour l’instant pour ainsi dire par grand chose comme éditeur SVG par exemple.

Enfin, à titre d’exemple, certaines technologies resteront exclusives comme le Smooth Streaming (streaming adaptatif en temps réel en fonction de la bande passante et du CPU) ou Sketchflow permettant de réaliser très rapidement du maquettage visuel. Bref, HTML5 mangera une partie des scénarios d’usage de Silverlight de manière standardisée et c’est tant mieux ! Mais Silverlight, grâce (ou à cause en fonction du point de vue ;-)) à son mode de développement propriétaire géré par un éditeur unique, proposera toujours une avance technologique sur les standards tout en garantissant le même rendu et possibilités au sein des navigateurs supportés.

Silverlight vous apporte ainsi dès aujourd’hui sur les navigateurs déjà déployés (IE6/IE7/IE8/Chrome/Firefox/Safari sur PC/Mac et Linux) une expérience RIA dont on pourra bénéficier en partie à travers HTML5 dans quelques années. Et pendant ce temps-là, Silverlight aura continué d’apporter son lot d’innovations… Autre facteur qui peut être déterminant dans le choix technologique : la capacité à écrire vite une application de qualité et maintenable par tout le monde. Un développeur issu du monde Java, .NET client lourd ou tout autre monde maitrisant les concepts objets n’aura aucune difficulté à maîtriser le framework .NET de Silverlight et à rapidement créer une application de qualité. L’outillage Visual Studio 2010 lui proposera même une expérience de debugging/d’optimisation de haut vol, la possibilité de faire facilement des tests unitaires, etc. Nous voyons certes aujourd’hui de très belles démos technologiques faisant appels aux futurs standards (il n’y qu’à voir la derrière en date du jeux de démo IE9 : Flickr Explorer). Mais les moteurs d’animations ou moteurs physiques derrières imposent une grande maitrise de JavaScript ce qui me parait personnellement moins évident que d’effectuer la même chose avec C# ou VB.NET en Silverlight… le tout avec au final un code compilé et non interprété sur l’ensemble des navigateurs. Mais tout cela dépendra bien évidemment de vos propres compétences.

Nous le savons donc très bien : il n’y pas une réponse unique à tous les types de développements Web. C’est pour cela que nous investissons dans les différents mondes de manière complète et engagée. Notre objectif étant de vous fournir le choix tout en vous garantissant le niveau de qualité et de performance optimal. Nous resterons donc présents sur les technologies standardisées par le W3C dont nous sommes membre (et même Co-Chair du groupe de travail HTML avec Paul Cotton), sur des technologies RIA type AJAX 4.0 ou jQuery tout en continuant d’investir sur notre propre solution Silverlight. Libre à vous ensuite d’évaluer l’intérêt de l’utilisation de telle ou telle technologie en fonction de vos besoins, de votre expérience, de vos contraintes et/ou de celles de votre client voire même de… votre philosophie !

David Rousset

Comments

• Anonymous
  May 12, 2010
  je suis novice sur internet mais si je peux accelerer mes recherches & mes e-mails je suis preneuse

• Anonymous
  May 12, 2010
  l'essayer pour voir les capacites

• Anonymous
  May 12, 2010
  je voudrais l'essayer pour voir la difference avec Firefox merci.

• Anonymous
  May 12, 2010
  Ayant cessé d'utiliser Internet Explorer depuis de nombreuses années, je suis très heureux de voir que Internet Explorer revient dans la bataille des navigateurs grâce à son meilleur support des standards, un moteur javascript décent, et se paie même le luxe d'offrir des avancées technologiques comme l'accélération matérielle. Je pense que Microsoft a compris qu'avec un moteur à la pointe de la technologie, ils pourront se permettre de développer des applications web riches et rapides, et peut être mettre fin à la mauvaise image de Internet Explorer en ce qui concerne le support des standards. Impatient de pouvoir tester la version finale.

• Anonymous
  May 12, 2010
  Article très intéressant, bien documenté. Bravo pour votre ouverture d'esprit. Je suis totalement d'accord avec Gabriel H. Pour ma part, je ne suis pas près de quitter Opera, mais IE devient un navigateur très intéressant.

• Anonymous
  May 12, 2010
  je souhaite essayer explorer 9

• Anonymous
  May 12, 2010
  je souhaite essayer explorer 9

• Anonymous
  May 12, 2010
  Bonjour à tous, Merci pour vos retours. Pour ceux qui souhaitent tester IE9 dans cette version Alpha, vous pouvez le télécharger ici : http://ie.microsoft.com/testdrive/info/ThankYou/Default.html comme indiqué en début de cet article. Bye, David

• Anonymous
  September 17, 2010
  The comment has been removed

• Anonymous
  October 01, 2010
  Je rejoint tout à fait le commentaire de sampabs. Pour un developpeur Web IE est une horreur. Un seul exemple : border radius, inconnu au bataillon sur IE9, c'est une vilaine erreur.  Que de hack IE (On s'étonne de voir fleurir sur les sites "Non optimisé pour IEX" Je remarque tout de même que des améliorations ont étés apportées, mais n'empéche pas ce navigateur d'être toujours à la ramasse. A quand un franc coup de collier, en implémentant correctement les standarsd CSS et HTML (vous remarquerez que je ne donne aucune version) Bref du travail à produire encore.

• Anonymous
  October 07, 2010
  Je l'ai installer, et je pense que je vais réinstaller le 8!! Il n'y a rien qui fonctionne, mes pages sont complètement explosée!! lol En même temps c'est que la version béta, vivement la version finale pour rigoler..!

• Anonymous
  October 16, 2010
  En 2 secondes IE9 en bêta m'a déçu...!!!! Mauvaise compatibilité CSS,  Jquery, ça a détruit tous mes sites, plus de galeries photos... j'aimerais bien savoir avec quoi vous faites vos testes! vous présentez de gros graphiques comparatif avec les autres navigateurs, mais vous êtes pas au niveau!

• Anonymous
  October 16, 2010
  et je ne parle pas de la gestion des cookies, typo.... ce n'est pas motivant!

• Anonymous
  October 16, 2010
  ahahah jamais vu une beta aussi pourri!!!! le pire c'est qu'ils vont intégrer automatiquement cette daube sur touts les pc...

• Anonymous
  December 17, 2010
  Hello Messieurs, Je me permets de répondre rapidement. @sampabs, quand on cite quelqu'un entre guillements, il faut vraiment copier/coller ce qu'il a écrit et pas tenter de faire de la manipulation en donnant sa propre interprétation. Si tu t'intéresses un minimum au contenu du test ACID3 (créé par un ingénieur très connu de chez Google : Ian Hickson), tu verras qu'il contient dedans des tests sur des spécifications qui vont mourrir et qui n'ont plus lieu d'être. C'est pour cela que l'on ne souhaite pas être à 100%. Pourquoi faire? Pour supporter un truc qui n'existera plus dans les spécifications du W3C dans quelques mois? C'est d'ailleurs aujourd'hui la même approche de Mozilla avec Firefox 4. Les suites de tests HTML5 & co non officiels sont aujourd'hui tous mal conçus. Tester et valider le support d'HTML5 et des technologies associées (CSS3, SVG) est bien plus complexe que 100 tests unitaires à la ACID3. On considère qu'il faudra environ 60 000 tests unitaires pour valider les spécifications. Donc ACID3 utilisé comme argument est une vaste blague. Quand tu dis qu'IE ne comprends rien aux standards du Web, je suis d'accord avec toi pour la version 6 et 7. IE8 a parfaitement corrigé le tir et est un excellent navigateur supportant CSS 2.1 et HTML 4.01, les spécifications standards utilisées aujourd'hui en production et encore pendant quelques années je pense. @LiteBob. Border Radius est parfaitement supporté par mon IE9 Beta. Quels tests as-tu effectué ? Sur une démo que j'ai écrite il y a peu de temps : bookclub.cloudapp.net/WCFRIA_jQueryHTML5.html, cela marche parfaitement sur mon IE9. Tu as bien fait le test avec IE9 en mode standard? Tu as bien utilisé la version standard des specs et pas une version propriétaire à base d'extension -moz ou -webkit? J'aime bien sinon le genre de commentaires constructifs et dénués d'arguments sur "mais n'empéche pas ce navigateur d'être toujours à la ramasse". A la ramasse sur quoi? En performance, nous sommes désormais 1er sur le benchmark JavaScript SunSpider devant Chrome, Opera, FireFox. En accélération matérielle, nous sommes toujours loin devant les autres. Si tu parles de standards non terminés (voir parfois dangereux comme Websockets récemment), oui, nous ne préférons pas implémenter des brouillons en perpétuel mouvement et cela rassure nos clients. @Ju, je n'ai aucun problème avec jQuery de mon côté. Il y a effectivement quelques sites qui ont des problèmes de rendu CSS dans IE9 Beta sur lesquels nous travaillons sur la prochaine mise à jour. Nous (== les équipes de développements et nous-mêmes) faisons nos tests sur les sites majoritaires et les plus consultés du web. Sinon, je ne comprends pas trop de quoi tu parles sur le reste. Il faudrait que tu donnes des exemples. @doudou, je ne sais quoi répondre face à cet excellent argumentaire. :) Chapeau bas pour la qualité de ta plume. Bye, David Rousset

• Anonymous
  January 16, 2011
  The comment has been removed

• Anonymous
  January 17, 2011
  Ben moi perso, ça me rassure... Qui fait des erreurs dans sa vie ? Tout le monde. Qui essaye de regarder en arrière et de corriger ses erreurs ? Moins de monde... Ce que fait Microsoft pour son nouveau navigateur est plus qu'honorable, et "l’humble-té" de l'article ne fait que renforcer ma confiance en leur produit. Ils travaillent dessus, savent que leur image est ternis par IE6 (et je suis le premier à le dire, étant développeur web), mais essayent de se racheter, et surtout communiquent ! Mieux vaut tard que jamais, non ?

• Anonymous
  February 22, 2011
  Quand est il du Webgl et pourquoi microsift a laché, l unique language 3D officiel dans IE 4 pour sortir sont format qui n ets toujos pas un standard ? Vrml 2 est l unique languqge 3D du web, et celui qui dit qu il n est bon a rien ce language, je repondrai FAUX car reproduire sim city en javascript , il en est capaable ce gentil language 3d qui a 14 ans !!et silverlight, ou meme flash, n arrive pas encore a al sa hauteur vu leur place !! et ca toutrne aps sur des pc , qui ont 10 ans, alors que vrml 2 OUI ::) ^^ alors WEVGL ou pas dans IE 9 ? MERCI

• Anonymous
  December 11, 2011
  Pourquoi les commentaires ne sont pas postés? Y-aurait il de la censure chez Microsoft? Ou est passé mon message de fin novembre? On se casse la tête a faire des messages construit et microsoft les fou à la corbeille?

• Anonymous
  April 02, 2012
  Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,Censure,