En ce moment, je lis énormément de choses sur la “révolution du HTML5” et la façon dont le HTML4 est supplanté par cette nouvelle itération pensée pour les applications en ligne. Je ne sais pas trop d’où sort cet adage que l’HTML5 est LE langage des applications en ligne, toujours est-il que je ressens comme une ambigüité persistante à ce niveau.
Pour schématiser, un site est un ensemble de pages qui forme un tout cohérent (comme un magazine). Une application est un outil offrant de fonctionnalités. Selon cette définition, dire que HTML5 est le langage des applications en ligne et qu’à l’avenir tout sera application est un non-sens. Je vois plutôt HTML comme un langage versatile permettant de faire tout un tas de choses, plutôt que de réduire ça à la notion d’application. Pour mémoire, le W3C a essayé pendant des années d’imposer XHTML2 et de faire accepter l’idée que toutes les pages sont des applications, nous savons tous comment cela s’est terminé. Pour être certain qu’il n’y ai pas d’ambigüité, je précise que HTML5 n’est pas remplaçant de XHTML2.
Mais revenons à nos moutons : les applications en ligne sont donc des outils offrant des fonctionnalités aux internautes. Dans la cadre d’une application de gestion de projet ou d’édition de document, tout est limpide. Mais si cette fameuse fonctionnalité est d’afficher du contenu, tout se complique. Pourquoi donc un éditeur de sites voudrait utiliser une application pour afficher du contenu ? Tout simplement pour améliorer l’expérience utilisateur. Deux des sites les plus populaires au monde sont ainsi des applications en ligne permettant d’accéder à des contenus : Facebook et Twitter.
En fait, tout a commencé avec Gmail qui a été le premier site avec une très large audience à utiliser Ajax pour faire des rafraichissements silencieux des pages. Cette technologie n’est plus toute jeune (elle existait déjà au siècle dernier), mais très peu de sites l’utilisent dans le cadre de contenus textuels. Cette réflexion est initialement venue d’une discussion très intéressante que j’ai eue avec Alexandre Malsch, le fondateur de Melty.fr. Pour celles et ceux qui ne connaissent pas, il s’agit d’un des portails les plus populaires auprès des jeunes.
Si vous visiter Melty.fr, vous aurez une expérience de visite assez similaire à n’importe quel portail, pourtant lorsque que vous arriverez sur le site pour la première fois, c’est le moteur d’affichage qui sera téléchargé en premier, car c’est lui qui gère l’affichage des contenus ainsi que les interactions. Ce moteur, développé en javascript, se positionne ainsi entre le navigateur et l’utilisateur et va intercepter les clics et défilements de la souris pour les interpréter à sa façon et proposer une navigation avec des rafraichissements silencieux qui évitent de recharger à chaque clic des éléments qui ne changent pas.
Les bénéfices de ce moteur d’affichage sont les suivants :
- des temps de chargement plus courts ;
- plus de faciliter dans les fonctions de partage ;
- un meilleur contrôle de l’expérience de lecture ;
- une analyse beaucoup plus fine des parcours et interactions des utilisateurs.
Dans l’absolu, maintenant qu’ils disposent d’une application de lecture pour les ordinateurs, ils peuvent proposer une expérience de lecture très cohérente sur les autres terminaux en proposant des moteurs optimisés pour les tablettes, les smartphones, les TV connectées… Une hypothèse tout à fait intéressante au vu du phénomène de fragmentation des terminaux mobiles, et surtout une réponse tout à fait viable aux problèmes de connexion et de stockage des contenus hors-ligne.
Les premiers utilisateurs de PDAs seraient alors tentés de me faire remarquer que ce n’est ni plus ni moins qu’une reformulation des lecteurs de news du siècle dernier comme AvantGo. Certes, il y a un peu de ça, mais je préfère plutôt saluer la volonté des équipes de Melty de proposer une expérience de lecture maitrisée de bout en bout sans avoir à se reposer sur des applications comme Instapaper ou Pocket.
Je vous rassure : moi aussi j’ai été très perturbé à l’idée d’utiliser un moteur d’affichage pour remplacer celui du navigateur, car c’est toute ça raison d’être ! Toujours est-il que ce site apporte des solutions là où d’autres sont dans une impasse (expérience de lecture maitrisée quel que soit le terminal, gestion des contenus hors ligne, analyse détaillée…). Je serais bien incapable de vous dire si au final cette solution est mieux que de se reposer sur le moteur de rendu natif des navigateurs, car “mieux” est une notion subjective. La discussion reste donc entièrement ouverte…
est-ce que plus que HTML5, ce n’est pas tout simplement javasciprt qui fait qu’une page devient une application potentiellement à part entière ? un langage de script intégré dans une page web permet de faire beaucoup de chose.
Effectivement c’est javascript qui permet de transformer une page statique en application. On peut même pousser le concept à l’extrème et ne plus avoir de HTML dans la page, juste du javascript – qui utilise évidemment HTML pour l’affichage – mais c’est bien javascript le coeur du système. Un trés bon exemple est le framework ExtJS (www.sencha.com). Le résultat est équivalent à une application lourde classique (menu, fenêtres, formulaires, etc…) dans le navigateur. C’est évidemment une hérésie si on se réfère aux principes de l’hypertexte, mais ça permet de répondre à un besoin particulier. Il ne faut évidemment pas penser en terme d’application là où on parle de site web (on voit mal comment transformer Wikipedia en “application”), il s’agit bien de deux conceptions différentes basées sur la même plateforme technique.
@ Laurent > Oui oui, c’st javascript qui transforme une page en application.
@ Jigso > Heu… même si tout est géré avec javascript, il faut bien une page HTML qui appel le fichier javascript quand même ! Sinon non, il serait tout à fait envisageable de faire de Wikipedia une application. Un wiki n’est-il pas une grosse application ?
Quand on dit “HTML5 est LE langage des applications en ligne” il faut effectivement penser a l’API Javascript de Html5, le HTML n’est qu’un langage de structuration des informations. Même si la version 5 apporte quelques balises intéressantes pouvant aider ( ou par ex.), c’est bien JS qui s’occupe de la partie chargement dynamique des données et interactions avec l’utilisateur.
Le javascript est loin d’être un langage neuf (il existait aussi au siècle dernier) mais l’arrivée de html5 est l’occasion de lui ajouter des fonctionnalités spécifiques pouvant être utilisées pour des applications, d’où une confusion fréquente , généralement entretenue par simplification.
Nb: les exemple ne sont pas passés, je citais les balises menu et canvas …
@ Jigso > Heu… même si tout est géré avec javascript, il faut bien une page HTML qui appel le fichier javascript quand même ! Sinon non, il serait tout à fait envisageable de faire de Wikipedia une application. Un wiki n’est-il pas une grosse application ?
C’est là que nos conceptions divergent, j’ai probablement une approche trop technique. Pour moi wikipedia est un site web, cad un ensemble de pages statiques reliés entre elles. Le navigateur passe d’une page à un autre en oubliant ce qu’il vient d’afficher. On est en plein dans l’hypertexte. Et les fonctionnalités d’édition ne sont que des micro-applications locales à chaque page, ça ne change pas la nature essentiellement statique du site web (si un simple formulaire transforme un site en application, tous les sites sont des applications ! ).
À l’opposé on a des applications web, comme par ex : http://dev.sencha.com/deploy/ext-4.1.0-gpl/examples/feed-viewer/feed-viewer.html, c’est un lecteur de flux rss.
Ici point de HTML écrit (regardez le source, le body est vide), tout le HTML est généré et modifié dynamiquement par le javascript.
Plus de liens hypertexts, ce n’est plus indexable, on reste en permanence dans la même page. Le navigateur devient alors l’OS qui exécute un programme.
Entre les deux on trouve évidemment toutes les déclinaisons possibles : de l’application “old-school” où tout se passe coté serveur, le moindre click recharge une nouvelle page HTML générée par le serveur, au site web enrichie à l’Ajax et autres JQuery, ou à une refonte du moteur de gestion du site comme Melty.
Ce que je trouve particulièrement excitant est qu’un même socle technique HTML5/Javascript permet de répondre à des contraintes d’architectures complètement opposées, je n’ai pas le souvenir que des langages ou des frameworks aient déjà réussi un tel grand écart par le passé.
Les frontières deviennent de plus en plus floues.
Je recommande de lire ceci:
http://blog.octo.com/dun-site-mobile-a-une-veritable-application-web/
Sinon le parfait exemple: L’achat de billet de Train en ligne.
D’un côté le bien connu:
http://www.voyages-sncf.com/
De l’autre:
http://www.capitainetrain.com/
Les chanlangers ont pris exactement le contrepied de voyages-sncf.
Une approche minimalise, ils se focalisent sur les billets de train (sans tout le reste)
Technologiquement on est sur ce qui est décrit dans le billet d’octo ou dans ce billet… On se rend sur une première page qui charge la logique. Ensuite cette page (coté client) fait des appels AJAX au serveur, récupère des données qui sont mis en forme par l’application JS côté client.
C’est très réussit, surtout comparé à la lourdeur de voyages-sncf, qui nous affiche une petite page de pub entre une requête et les résultats histoire de faire patienter…
Qu’entendez-vous par “application de lecture pour les ordinateurs” ?
merci