On peut observer une montée en flèche de l'utilisation d'AJAX, terme également pompeux pour désigner une méthode javascript permettant d'appeler des fichiers externes sans recharger de page (sensés être au format XML comme l'acronyme au goût de lessive le fait penser, mais c'est en fait facultatif) et c'est aussi un réel progrès, mais qui doit être nuancé.

Certains, comme Fred Cavazza, sont très enthousiastes quand à cette technologie novatrice (bien qu'ancienne), alors que Laurent Jouanneau (un des "messieurs xulfr") la trouve «déjà obsolète». Qu'en est-il vraiment ? Qu'AJAX apporte-t-il et que n'apporte-t-il pas ?

Tout d'abord, le volet de cette technique qui sera abordé dans ce billet est celui qui peut servir lors de la créations d'outils interactifs en relation avec le visiteur et dans les cas où vitesse et ergonomie sont très importants : notamment l'échange de données sur une page restant en majorité la même. Ceci dit, l'utilisation d'AJAX doit se faire avec des pincettes pour ne pas handicaper la navigation en supprimant complètement les boutons Précédent et Suivant et est pour cette raison inadaptée dans les sites statiques. De plus, il faut faire bien attention aux défauts de ce mélange de JavaScript et d'XMLHttpRequest et ne l'utiliser que s'ils sont contournables ou ne s'appliquent pas : il s'ahit d'aider le visiteur, pas de le pénaliser.

Avec l'avènement des technologies de plus en plus poussées, l'ADSL qui devient très répandue, l'impatience nous gagne. Les temps des modems 56K sont oubliés, et chaque seconde d'attente devant une page blanche en connexion devient une éternité. C'est dans ce contexte qu'AJAX réussit si bien sa petite envolée : il neutralise les temps de chargements les plus courts. Un des aspects de cette technologie est le dialogue avec le serveur en utilisant uniquement les données nécessaires, comme observable sur une des démos d'OpenRico, inclusion de code HTML. La navigation acquiert une dimension plus intéressante et surtout plus agréable : c'est instantané. N'en déplaise à Laurent, c'est efficace.
L'autocomplétion est aussi très utile et bien plus performante que le schéma actuel :
taper le nom. envoyer le formulaire. voir la page se recharger. lire les solutions. voir une faute d'orthographe dans le nom. retaper le nom. réenvoyer le formulaire, puis réattendre le chargement de la page.
C'est là que l'on voit le principal interêt d'AJAX : la vitesse et l'ergonomie. Car non seulement c'est bien plus rapide, mais c'est un indéniable atout question accessibilité : l'autocomplétion, par exemple, facilite et simplifie la tâche de l'utilisateur qui n'est plus obligé de trouver le terme exact et qui peut se tromper sans perdre le temps d'un énième rechargement de page.

Laurent soulève ensuite le problème de la taille imposante des scripts tous faits comme Prototype (bien qu'il ait fortement perdu du ventre depuis son billet), mais à mon sens, c'est une question qui trouve sa solution dans ce que le fichier apporte.
Effectivement, que sont 50ko sur la navigation d'un site ? Au pire, ils ne se téléchargent pas, et le site reste disponible sans le script, au mieux, tout fonctionne. Et si chaque visiteur a une moyenne de 15 pages vues, (on ne parle pas de site institutionnel ou vitrine mais bien un outil interactif) le gain de vitesse entraîné par la validation sans rechargement de 2 formulaires compense la perte occasionnée par les 50ko à télécharger. À la seule différence que le script a été récupéré sans que l'internaute ne s'en rende compte, alors qu'il doit bien attendre les pages entières de validation de formulaires.

Il nous parle aussi du débuggage et de la maintenance. Quel débuggage, quelle maintenance ? Ceux d'un site Internet, oui, mais je ne vois pas bien ce que les scripts permettant d'AJAXer facilement ont à voir là dedans. Quand on utilise le support SVG dans XUL pour faire une application graphique, les temps de débuggage et de maintenance ne sont augmentés que par l'augmentation de la taille de l'outil, et ne sont en aucun cas liés à l'utilisation d'une technologie tierce. Quand on parle d'utiliser Script.Aculo.Us par exemple, je ne vois pas ce que l'on devrait "débugguer et maintenir" de plus que sans cette librairie : quand on fait un site en utilisant Spip, on ne s'occupe pas à débugguer l'outil ou à le maintenir, on l'utilise, tout simplement.

Laurent compare ensuite AJAX à la balise <a>, c'est ici de la pure mauvaise foi qui ne mérite même pas d'être relevée, tant les moyens, les objectifs et la méthode n'ont aucun rapport.

Le reste du billet est plus constructif et plus intéressant. L'idée serait de standardiser ce qu'AJAX permet dans XUL (et donc seulement dans la branche SeaMonkey, Firefox et Camino). En soit, ce serait une bonne chose car plus simple et plus propre, mais c'est irréalisable dans l'immédiat et surtout inutilisable. Quand on nous parle d'accessibilité puis d'incompabilité avec IE, Safari et Opera, il y a un certain décalage dans le propos. Si standardiser l'échange d'informations à l'intérieur d'une page serait BON pour le Web, le terme XUL me semble hors-sujet. En quoi le langage d'un des différents navigateurs interviendrait-il dans les pages Internet ? La syntaxe de telles fonctionnalités devrait être définie par le W3C (seulement après un accord avec les éditeurs de navigateurs, pour que ce travail ne serve pas à rien : si seuls Firefox et Opera implémentent ces nouvelles méthodes, c'est inutile) et être générique.
Mais, au risque de paraître pessimiste, à la vitesse à laquelle évoluent les normes et au vu des divergences entre les différentes équipes de développement (bien que la nouvelle équipe IE paraisse plus ouverte), trouver un consensus me paraît pour le moment bien compromis.

Au final, la conclusion que l'on peut tirer est qu'AJAX permet de faire avancer l'ergonomie du Web en repensant les échanges internautes/sites, d'augmenter parfois considérablement l'usabilité d'une application, et que cette solution est aujourd'hui fonctionnelle en étant bien utilisée. Elle le sera d'autant plus avec la standarisation du protocole XMLHttpRequest (IE7 va abandonner sa méthode propriétaire pour se ranger au même niveau que tous) et avec les progrès à venir des librairies AJAX. Seulement, il convient bien évidemment de faire attention à son utilisation et de ne pas l'employer à tout va, et surtout de ne pas oublier proposer une solution alternative plus classique en prévoyance du cas où ça ne pourrait pas fonctionner (navigateur incompatible, JavaScript désactivé, ActiveX interdit, ...).

Liens

  • Traducteur AJAX : efficace, hein Laurent ;)
  • Les sondages de Scoopeo : c'est vraiment agréable à utiliser
  • Zicabox, une application française qu'elle est bien
  • Le meilleur du Web 2.0 : l'écrasante majorité de ces applications utilisent AJAX et le font bien, elles sont à tester