Depuis quelques années, le HTML a largement évolué. Ce format de document qui a l’origine destiné uniquement à afficher un texte structuré et à créer des liens entre différentes pages a été largement malmené au cours de son existence. Alors que la version 5 du « standard » vient d’être finalisée, il est à mon sens bon de revenir sur son évolution et ses usages parfois inadaptés.
L’historique
Ainsi, à ses débuts le HTML était très simple. Pas de mise en forme évoluée, pas même d’images, de tableaux ou de formulaires. Il a été créé dans un but purement scientifique d’échange d’informations. Ce qui à l’époque était totalement novateur comparé aux usages du net existants alors (emails, usenet…). Il a par ailleurs été, un temps, concurrencé par le Gopher, un protocole assez proche dans l’esprit mais qui n’a pas réussit à évoluer aussi vite et s’est incliné face au succès du web.
Cependant assez vite les gens ont voulu faire bien plus avec le web que de basiques pages blanches remplies de texte noir sans mise en forme ou presque. Ainsi au fil des évolutions des navigateurs, le formats HTML a été largement remanié. Les images ou les formulaires sont arrivées grâce au premier navigateur de renom, NCSA Mosaic. Ce dernier ayant été rapidement dépassé par ses deux successeurs spirituels, Netscape et Internet Explorer. Nous connaissons tous ou presque la guerre qui a fait rage dans les années 94 à 2000 entre les deux frères ennemis. Au delà des pratiques plus ou moins concurrentielles pures comme l’intégration au sein du système d’exploitation de Windows du logiciel de Microsoft, chaque navigateur a rapidement cherché à se démarquer du voisin en apportant des nouvelles fonctionnalités.
Difficile de faire une liste exhaustive des apports de chacun, mais en à peine 4 ou 5 ans, quasiment tous les éléments principaux du langage HTML que nous connaissont ont été inventés par l’un ou l’autre, et souvent repris ou adapté ensuite. Ainsi, en vrac, les tableaux, frames puis iframes, structuration du DOM, intégration du javascript, intégration du CSS, création des div et autres span, création des appels asynchrones (ajax)…
Le HTML a ainsi servi à tout et surtout à n’importe quoi. Avant que les navigateurs se mettent réellement d’accord sur la bonne pratique d’usage des CSS, il n’était pas rare voire conseillé d’utiliser les tableaux pour créer la mise en forme d’une page internet. Pratique très fortement déconseillée et qui n’existe heureusement presque plus de nos jours mais qui a eu son heure de gloire.
Les années passant, le succès du web grandissent, il devenait nécessaire de structurer tout ça. C’est à ce moment là que l’organisme « normalisant » le standard HTML, le célèbre W3C, s’est attelé à reprendre et structurer les idées de chaque camps afin de définir un « standard » (ou souvent appelé recommandation). Ainsi les versions 3.2 puis 4 du HTML ont eu pour but de fixer et organiser les avancées de chacun afin de définir comment doivent fonctionner les navigateurs pour que les sites s’affichent de la même manière d’un logiciel à l’autre. Evidemment la chose ne s’est pas faite en un jour, et même aujourd’hui il reste des choses qui ne sont pas gérées de manières identiques… Cependant avec le temps l’écart s’est largement réduit et il devient difficile de déconseiller un navigateur sur ce plan là, même Internet Explorer qui traîne une très mauvaise réputation arrive à s’en sortir honorablement de nos jours.
Dans le même temps est arrivé le web dit « 2.0 » et le célèbre HTML 5. Combinant non seulement les évolutions du HTML mais aussi toutes les nouvelles techniques associées (CSS 3, JavaScript, WebGL, Canvas, HTML Forms…), le langage qui n’en est pas vraiment un est devenu une véritable plateforme de développement universelle, simple à mettre en place et utilisable quasiment partout. Car dans le même temps, le web a réussit son parti de gagner tous les supports. Du smartphone à la télévision connectée, de l’ordinateur à la tablette, de la console de jeux aux liseuses numériques, tous partagent ce dénominateur commun de compatibilité logicielle.
Le HTML applicatif
De cet état des choses, plus d’un développeur a eu l’idée de profiter de cette compatibilité universelle pour utiliser le HTML (et consorts) comme plateforme de développement pour les applications. Sur le principe rien de plus « sexy » en effet, le célèbre moto « write once, run everywhere » (écrire une fois, exécuter partout) prenait enfin vie, là ou le Java a échoué 10 ans plus tôt. Et c’est ainsi qu’on a vu apparaître de nombreux exemples qui reposent sur cette capacité.
Un des exemple les plus frappant, à sa sortie, l’iPhone ne proposait aucune possibilité d’installer une application, l’AppStore n’existait en effet pas ! Le seul moyen à l’époque, mit en avant par Apple, était d’utiliser ce qu’on appelait alors des « webapps ». L’entreprise de Cupertino possède toujours sa page dédiée sur son site (http://www.apple.com/webapps/) proposant tout de même plus de 5000 références…
D’autres développeurs ont décidé d’aller plus loin, en proposant ni plus ni moins que tout un système d’exploitation soit basé uniquement sur ces technologies. Les exemples ne manquent pas, l’un des premier du genre fut WebOS créé initialement par Palm au destin que l’on connait, mais même plus récemment, de Firefox OS (ex Boot 2 Gecko) de Mozilla, Tizen de Samsung et Intel, ChromeOS de Google et bien d’autres encore…
Une bien mauvaise idée ?
Pour autant, il faut tout de même le dire, à ce jour, aucune application développée ainsi n’a eu le succès escompté. Je précise toutefois que par « webapp » j’évoque ici les applications pures et non les services en ligne type GMail qui fonctionnent au sein d’un navigateur web classique. Je ne parle donc que des applications qui s’utilisent « directement » hors navigateur.
Ainsi, du côté des webapps, que ce soit les versions « made in Apple » ou les applications classiques utilisant des vues HTML comme on a pu le voir dans la célèbre application mobile Facebook sur iOS et Android, le résultat était très loin du compte. Performances très loin de ce qu’on est en droit d’attendre de nos appareils modernes, interfaces souvent inadaptées aux systèmes sur lesquels ils tournent et fonctionnalités fortement en retrait. Le fait de ne pas utiliser les outils « natifs » a fortement handicapé ces applications, et on le voit assez rapidement dans les commentaires des utilisateurs. Le pourquoi de la chose est assez évident, si nos appareils se débrouillent pas mal pour afficher des pages web classiques, dès que les éléments « riches » et programmés en JavaScript se multiplient, les performances chutent nettement. Surtout comparé aux applications natives qui sont elles compilées et exécutées sans aucune interprétation (ou presque) par le système, là ou en HTML différentes couches entrent en jeux pour réaliser les mêmes actions. Facebook a justement récemment fait évoluer son application en passant en pur « natif », ce qu’ils ont perdu en simplicité de développement multi plateforme, ils l’ont largement gagné en efficacité ! Sans même parler de l’impact sur la batterie, point pourtant crucial !
Alors bien évidement, quand il s’agit d’un système d’exploitation complet, il va sans dire que cette technologie perd alors tout son intérêt. Il est impossible pour une application HTML et JavaScript de s’exécuter dans des vitesses proches de celles d’une application native. Même si les dernières technologies impressionnantes intégrées aux navigateurs permettent d’accélérer les choses, l’écart reste un gouffre insurmontable. On l’a bien vu avec le célèbre jeu Angry Birds, jouable en ligne sur le navigateur Chrome, il a tout le mal du monde à être aussi fluide que sur un simple smartphone d’il y a 2 ans !
L’échec de WebOs n’est pas uniquement dut à sa commercialisation catastrophique, les idées étaient pourtant nombreuses et intéressantes, mais les performances du système ne pouvaient tout simplement pas rivaliser avec les autres systèmes. Il n’y à qu’à voir les retours des tests de la célèbre tablette TouchPad (Journal Du Geek, Clubic…) pour comprendre que malgré un matériel en avance sur ses concurrents, principalement l’iPad, les performances étaient largement en retrait. La déception était donc grande et le public ne s’est vraiment laissé séduire par cette plateforme qu’à partir du moment ou le prix a été sacrifié par HP dans un désordre ahurissant (lire : HP met un terme à ses appareils WebOS !).
Alors, que dire quand on voit la tentative de Mozilla de répéter l’expérience, en allant même bien plus loin, avec Firefox OS qui sera à 100% basé sur du HTML ? Difficile à dire, mais il y a fort à parier qu’ils ne feront aucun miracle dans la fluidité et performance du système. Quand, de plus, on sait que leur objectif est de s’adresser aux appareils à bas prix… Je ne suis pas devin, mais il va être très difficile de proposer des produits qui intéressent le public qui peut pour un prix similaire avoir un appareil Android ou Windows Phone qui sera bien plus efficace.
Du côté de Chrome OS, les performances expliquent en partie l’échec du système à ce jour. En partie seulement car le système n’est pour le moment proposé que sur des appareils très peu diffusés mais également puissants, ce qui permet de compenser quelque peu les ralentissements. Surtout que toutes les applications sont soit des sites web classiques, soit utilisent la petite botte cachée de Google, ce qu’ils ont appelé « Native Client » qui permet d’exécuter du code « natif » directement dans une fenêtre de navigateur. Preuve s’il en est que même un système basée sur du HTML se doit de pouvoir offrir de la performances quand il y en a besoin.
Mais dans le futur ?
Dans le futur, la chose pourra évoluer. Bien évidement les performances du HTML sont et resterons en retrait avec celles d’une application native. Mais l’augmentation en puissance des appareils fera qu’un jour la frontière entre les deux sera suffisamment infime pour que, sauf quelques catégories, la majorités puissent être réalisées ainsi. C’est par ailleurs ce que j’expliquais ici même il y a plus d’un an (lire : HTML5 : le futur des applications mobiles !), mais si cette prédiction reste valable, elle n’est toujours pas pour demain !
