Qu'est que Ajax ?

Au départ, Ajax, pour Asynchronous JavaScript and XML désigne une technique qui est d'utiliser l'objet xmlhttprequest en javascript pour récupérer des données à partir d'un serveur web, puis de modifier le document courant en fonction de ces données, au moyen de l'api DOM xml. Rien de bien extraordinaire, au niveau du concept d'abord, puisqu'il s'agit d'utiliser ce qu'on appelle depuis quelques années les services web (que certains d'ailleurs ont renommé sous le nom ridicule de "Web 2.0 API", histoire de faire croire qu'ils font quelques choses de nouveau). Et ensuite au niveau des technologies puisque javascript, xmlhttprequest et DOM existent depuis des années déjà.

Cependant, avec la mode ajax, chez beaucoup de développeur, ce terme regroupe maintenant tout et n'importe quoi, à tel point que dés que l'on fait du drag and drop, ou que l'on fait du DOM, beaucoup croient qu'ils font de l'Ajax. (Pour ceux qui n'aurait pas compris : on fait de l'ajax quand on utilise xmlhttprequest, point barre).

C'est tout de même sympathique Ajax : modifier une partie d'une page sans tout recharger, meilleure expérience utilisateur etc. Il est vrai que du point de vue de l'internaute, c'est agréable. Il semble légitime alors que beaucoup de développeurs web s'extasient devant la magie d'Ajax (Et un certain illustre Gerard M. n'y est pour rien). Mais malheureusement, très peu s'interrogent sur les limites de cette technique, qui sont pourtant flagrantes et vite atteintes selon moi.

En effet, si on plonge dans le code javascript d'une page qui fait de l'ajax, on peut remarquer la chose suivante : c'est d'une complexité hallucinante par rapport à ce qui pourrait se faire. À moins d'être un développeur confirmé, c'est un parcours du combattant pour comprendre, analyser, modifier et maintenir le code. Du fait d'abord des différentes implémentations selon les navigateurs, mais aussi parce qu'il faut tout gérer : de la transaction HTTP avec le serveur (géstion du code retour, lecture du résultat), à la manipulation DOM (à moins d'utiliser le fameux innerHtml bien cra cra, mais pas toujours utilisable suivant les données que l'on récupère). Le debuggage, la maintenance, les temps de développements s'en trouve alors nettement alourdi et obscurci. Il est vraiment loin le temps des pages HTML simples.

Bien sûr, une alternative serait d'utiliser une de ces bibliothèques javascript toutes faîtes qui commencent à apparaître. Mais on se retrouve

  1. avec une nouvelle API à apprendre.
  2. avec des fonctionnalités qui ne sont pas forcément adapté à la prise en charge de service web existants.
  3. avec des pages bien alourdies de scripts dans tous les sens.

Bref, je trouve que cette technique laisse vraiment à désirer en terme de productivité et d'efficacité, et qu'il faudrait orienter les évolutions du web, non pas vers xmlhttprequest + DOM, mais vers d'autres concepts plus simple à utiliser dérivant de ceux que l'on trouve déjà dans... HTML !

Quand le html fait de l'ajax sans que vous le sachiez

La balise <a> en HTML par exemple. Pour comprendre, voyons comment elle fonctionne en gros :

  1. l'utilisateur clique sur la balise (ou l'active par un autre moyen)
  2. un événement DOM est envoyé sur la balise pour l'avertir de l'action
  3. sur l'arrivée de cet événement, la balise <a> a un comportement par défaut, définit par le navigateur, qui est :
    1. récupération de l'url située dans l'attribut href
    2. instanciation et utilisation d'un objet similaire à xmlhttprequest pour appeler le serveur web
    3. récupération du contenu
    4. remplacement du document courant par le contenu reçu

Ça ne vous rappelle rien ? À part le dernière étape qui est légèrement différente (seule une partie du document est complété ou remplacé), c'est ce qu'on fait en Ajax. Sauf qu'en Ajax, on s'embête à faire tout ça à la main, avec tous les risques de bugs que cela comporte.

Parce que c'est le navigateur qui fait tout avec cette balise de lien, on remarque donc qu'ici :

  1. c'est très simple à utiliser (mettre la balise et les attributs adéquates)
  2. c'est donc très rapide à développer avec une minimisation du risque de bug.
  3. ne nécessite pas 80ko de scripts additionnels.

En un mot : efficace. Ce que n'est pas Ajax.

L'idée serait donc de masquer toute la cuisine Ajax et ses 150 ko de javascript (oui, il y a inflation depuis 2 lignes, avec tout ce que mettent certains dans le sac Ajax..) et d'étendre le concept simple des balises <a> et <form> du HTML.

Des nouvelles balises magiques

Imaginons que le service web http://monsite.com/serviceweb/listeanimaux nous permette de récupérer une liste d'animaux, et renvoi donc par exemple ceci :

<animaux>
   <animal nom="girafe" />
   <animal nom="éléphant" />
   <animal nom="lion" />
</animaux>

Imaginons ensuite que l'on ait une balise <template>, que l'on pourrait utiliser comme cela :

<ul>
  <template id="mylist" datasource="http://monsite.com/serviceweb/listeanimaux" format="XML" ref="animaux/animal">
    <li><content value="@nom"/></li>     
  </template>
</ul>

Le navigateur, voyant la balise <template>, récupérerait le contenu situé à l'adresse indiquée dans l'attribut datasource, bouclerait sur chaque élément correspondant au chemin (au format xpath) indiqué dans ref, et pour chaque élément, générerait une balise <li> ayant pour contenu la valeur de l'attribut nom.

Vous voila donc avec du contenu généré automatiquement, à partir d'une source de donnée distante, sans une seule ligne javascript. Vous feriez alors de l'ajax sans le savoir. Comme avec la balise <a> ou la balise <form> du HTML.

Si à un moment ou à un autre (sur un clic de bouton par exemple), on veut modifier le contenu ou le rafraichir, il suffirait d'écrire une ligne javascript comme par exemple un document.elementById("mylist").datasource.reload() ou encore un document.elementById("mylist").datasource.href="http://monsite.com/serviceweb/listeanimaux?espece=poisson".

On pourrait aussi par exemple spécifier le type de format. Ici j'ai pris l'exemple du XML, mais ça pourrait être du JSON, un fichier CSV, du XML-RPC etc... La syntaxe des attributs ref et autre <content> ne serait alors certainement pas la même, mais on pourrait faire en sorte que cela soit proche de xpath. On pourrait aussi avoir une balise <conditions> qui nous permettrait de faire de la génération conditionnelle, ou d'autres comme dans ce que j'avais fait dans jsTemplateBuilder. Bien sûr, l'exemple présenté ici, qui pourrait être assimilé à un pseudo XSLT, est un peu léger, et pose certainement des problèmes dans certains cas. Ce n'est qu'un brouillon pour montrer le concept et ses avantages indéniables :

  • comme je l'ai dit, facilité d'utilisation, prise en charge d'opérations bas niveau, donc moins de bugs potentiels, moins de maintenance, meilleure évolutivité etc..
  • pages légères, sans 150ko de javascript à télécharger (et à maintenir).
  • c'est certainement plus accessible qu'Ajax (qui, mal utilisé, ne l'est pas du tout). Un analyseur de document, grâce aux balises template connaît les portions du document qui sont susceptibles d'être modifiées, donc peut surveiller ces modifications et en informer l'utilisateur (par synthèse vocale, via sa plage braille, ou visuellement). On pourrait même imaginer qu'un lecteur d'écran vocal lise l'attribut title de la balise parente (par exemple ici <ul title="liste des animaux">) et informe l'utilisateur la partie liste des animaux du document vient d'être modifiée, voulez vous la consulter ?. Certes, il pourrait aussi surveiller dans un document classique les événements de mutations DOM mais le lecteur vocal ne pourrait tout de même pas informer l'utilisateur de chaque ajout/suppression/modification d'un élément ou attribut DOM, ça deviendrait vite un cauchemar.

Du rêve à la réalité

Là vous vous dites, Laurent, c'est sympa ton truc, ce serait sûrement chouette, mais c'est beau de rêver, car ça n'existe pas. Vraiment ?

Pour être tout à fait honnête avec vous, je n'ai absolument rien inventé. En effet, ce système de template existe déjà. Et c'est ... Mozilla qui le propose depuis quelques années déjà : les templates XUL. Certes, pour le moment, le format des données est limité au RDF et c'est plus compliqué à utiliser que dans mon exemple, mais ça fonctionne et ça devrait s'améliorer dans le futur.

Ayant manipulé les templates XUL, je peux vous dire qu'Ajax est trop compliqué, et ne va pas nous amener bien loin, sauf au prix de d'efforts qui sont pour moi du gâchis. Ajax n'est pas adapté sur le long terme à du développement sérieux. Même si ça fonctionnera, vu tout le buzz et cet effet de mode qu'il y a autour. Mais ce n'est franchement pas la meilleure voie vers un web plus simple, plus sémantique, plus accessible...

Les contradictions du HTML et de l'ajax

Ce qui m'étonne, c'est que d'un coté, certains (comme Apple pour leur dashboard) prônent le HTML pour faire des interfaces d'applications web parce que soit-disant, le HTML c'est facile et tout le monde connaît, mais que d'un autre coté ils proposent de l'Ajax à toutes les sauces. Le résultat est que la simplicité du HTML est totalement masquée par la complexité d'Ajax au niveau développement. Alors qu'un peu de XUL...