HTML5 : la promesse d'un browser qui devient VM
Hier avait lieu une présentation de Peter Lubbers sur HTML5. Une présentation très sympathique qui permettait de repasser en revue les nouveautés d'HTML5, et elles sont nombreuses...
Au niveau langage tout d'abord. HTML5 déprécie certains tags (frameset, font...) HTML et en rajoute et tout ça dans un objectif de productivité, de faciliter et de mutualiser les bonnes pratiques. C'est finalement assez proche de la définition Lean de Standard. On retrouve ainsi
- des tags facilitant l'organisation du contenu (header, footer, nav...)
- CSS3 s'enrichit et offre un langage plus riche sur ces tags
- Les formulaires deviennent également plus simple à créer et HTML5, en tant que langage, propose à la fois des composants plus riches (date picker, slider...) et des mécanismes natifs de validation (validation d'un email...)
Au niveau multimedia ensuite avec des possibilités graphiques (vectorielles et bitmap) plus évoluées. Enfin la vidéo nativement supportée par le navigateur qui vient empiète des territoires jusqu'alors réservés au plugin Flash. Google (avec YouTube) supporte activement cette balise mais la bataille n'est pas encore gagnée : reste maintenant à se mettre d'accord sur le codec vidéo (Ogg, H264, VP8...) et il y a fort à parier que les guerres commerciales seront plus responsables de la pérennité d'un de ces standards que n'importe quel avantage technique.
Au niveau échange enfin et c'est certainement là que les évolutions sont les plus riches.
- Les Web Sockets (supportés uniquement par Chrome) représentent la plus belle innovation dans ce domaine. Un nouveau protocole basé sur TCP qui permet d'ouvrir une connexion "permanente" entre le browser et le serveur et de faire transiter de la donnée entre les deux. Simuler le push server est possible avec des solutions comme Comet (standardisé dans Servlet 3.0) mais induit un overhead important en termes de bande passante du en grande partie aux headers HTTP. WebSocket améliore ce point (puisque les headers sont échangés à l'instanciation de la connexion) et ouvre la porte à des applications Web "temps réel". Une technologie qui trouve déjà des mises en oeuvre dans les jeux (pour échanger l'information entre joueurs), les IHM de monitoring...De plus Web Socket étant un protocol, il (1) devrait être supporté par les Firewall, les proxies et autres routeurs et (2) pourrait être utilisé par d'autres clients que des clients JavaScript (client Java et IHM Swing par exemple). HTML5 tend aussi à normaliser les principes de Comet au travers des Server Sent Events, à voir dans quelle mesure cela ne fait pas doublon avec les Web Sockets.
- Web Worker permettra d'exécuter une tâche en background (et les implémentations utiliseront les mécanismes de thread pour utiliser au maximum les processeurs multi-coeurs). Avec les Web Worker, on s'approche d'un modèle évènementiel où le navigateur (via JavaScript) envoie et réagit à des évènements ad-hoc.
- Les mécanismes de Web Storage qui enrichissent fortement ce qu'on pouvait faire (avec limitations) avec des cookies et visent à stocker plus d'information au niveau du navigateur. Ainsi, on note l'apparition des Session et Local Storage Area que l'on peut apparenter à des stockages key/value et un Web SQL DB qui reprend les principes d'une base de données relationnelles. On notera également le principe de Offline Web Application qui est repris et propose un mécanisme de cache locale de ressources statiques, permettant ainsi de développer des applications web résilientes à la perte de connexion web.
Et pour finir au niveau sécurité puisque HTML5 remet en cause certains principes autour de la Same Origin Policy et permettra de faire des requêtes Ajax sur des domaines différents (XmlHTTPRequest level 2)
HTML5 est donc la promesse d'un navigateur plus riche. Plus qu'un simple interpréteur HTML, le browser devient une machine virtuelle : capable d'exécuter de manière performante (en tout cas pour les dernières versions) JavaScript, permettant de stocker sur le client un maximum de données et soulageant d'autant les infrastructures, la consommation de bande passante. Les évolutions autour des nouveaux types d'échanges (Web Worker et Web Sockets) vont nécessiter un vrai travail d'"usability" pour tirer partie des ces nouvelles possibilités techniques.
Le frein le plus important reste le support partiel et non uniforme des différentes évolutions par les différents navigateurs. Un support hétérogène qui demandera de bien connaitre ses utilisateurs et leurs habitudes de navigation pour distiller, au cas par cas, ces nouvelles fonctionnalités. Enfin, le support officiel que porte Google et Apple à HTML5 va demander à Adobe d'innover avec la plateforme Flash (offrir des fonctionnalités qu'HTML5 ne propose pas, faciliter les développements autour des ces fonctionnalités) au risque de péricliter.