Ajax, le renouveau de javascript

Javascript est un langage qui existe depuis très longtemps, mais son potentiel a été très mal utilisé.
Depuis l’arrivée de Ajax, c’est le renouveau de Javascript. On s’y intéresse de nouveau, et c’est tant mieux.

Ajax, les côtés positifs

flux maîtrisé

Ajax permet d’avoir un flot maîtrisé entre le client et le serveur.

• Meilleure répartition des charge;
  • on gère mieux les charges CPU car au lieu de balancer une requête, on va en créer plusieurs, réparties dans le temps,
    • exemple: au chargement d’un site, on fait les chargement progressivement,
  • on charge les fonctionnalités quand on en a besoin,
    • exemple: si l’utilisateur demande une information particulière on charge la partie fonctionnelle par requête Ajax,
  • on déplace le travail sur le poste client plutôt que de tout faire sur le serveur,
• Flux asynchrone; on peut par exemple vérifier un champ d’un formulaire grâce à une requête Ajax, sans avoir à faire un chargement total de la page.

Ergonomie Améliorée

L’ergonomie est généralement (mais pas tout le temps) améliorée grâce à l’utilisation d’Ajax.

• Chargement de la page plus rapide
  • une page étant à l’écran, je charge ce dont j’ai besoin. Le temps de chargement est beaucoup moins long que de tout recharger
• Meilleure interaction entre l’utilisateur et le site
  • je charge des images, textes,… qui font patienter l’internaute. Une requête synchrone (sans Ajax) donnerait un écran blanc tant que toutes les ressources ne sont pas chargées,
  • si je ne charge qu’une partie de la page, l’utilisateur peut (si besoin) continuer à lire du contenu en attendant,
  • pour un formulaire,  je peux faire des vérifications sans avoir à tout recharger, cela donne un confort d’utilisation incomparable,
  • l’auto complétion (cette fonctionnalité qui permet de proposer des mots en se basant sur les quelques lettres tapées) se base aussi sur Ajax. On ne recharge pas tout, ce serait inutilisable.

Les côtés obscur d’Ajax

L’utilisation d’Ajax peut parfois être contre-productive.

Plus délicat à mettre en oeuvre

La programmation Asynchrone est toujours plus délicate à mettre en oeuvre que la programmation Synchrone.

Problème sur :

• Consistance des données. Je fais une requête Ajax et en même temps l’internaute peut agir sur le site…
• Collisions
• Fuite de mémoire (on empile les requêtes, on charge des widgets et on ne la libère pas)
• Maîtrise des priorités des événements

D’autre problèmes touchent plus l’ergonomie:

Il y a plusieurs origines à une requête. L’internaute appuie sur une interface (bouton, liens, textarea, input…) ou bien la requête est lancée sans que l’internaute agisse, dans ce cas les requêtes sont périodiques et programmées dans le site.

Par exemple, les messages qui s’affichent dans une zone (périodiquement une requête Ajax est lancée pour scruter les messages sur le serveur et les afficher dans une boiboite)

Dans ce dernier cas l’utilisateur peut ne pas s’attendre à de tels changements, et donc y passer complétement à côté.

C’est pourquoi, d’un point de vue Ergonomique, il faut essayer de toujours avertir l’internaute qu’une information issue d’une requête Ajax est arrivée.


Cela peut être par:

• un clignotement,
• un changement de couleur,
• un son,
• une baffe…

Pour des personnes ayant quelques difficultés visuelles, l’utilisation peut être réellement problématique, il faut donc indiquer le changement / chargement d’infos.

Autre problème réside dans le bouton “back” des navigateurs

Pour un internaute de plus de 40 ans, le fonctionnement des sites est souvent obscur et particulièrement, le mélange entre Ajax et bouton “Back”.

Le bouton “Back” n’annule en rien une action générée par Ajax. On peut se retrouver avec un système instable et un internaute perdu.

Problème sur la prise en compte des modifications du DOM

Lorsque l’on touche le DOM (ce n’est pas propre à Ajax, on peut le faire sans requête, mais avec Ajax on le fait systématiquement) le code vue par un robot, crawler, reste inchangé par rapport à la page Html chargée initialement.

Idem si on fait Ctrl+U pour visualiser le code Html de la page modifiée. Ce code reste inchangé.

Admettons que votre code html se résume à une zone d’affichage et que cette zone se rafraîchisse via Ajax. Le référencement (si aucune autre action n’est prise pour contrebalancer ça) risque de poser problème vue que le robot d’indexation ne verra que le code originel (et pas original).

Ajax se base sur n’importe quel élément html qui pourrait provoquer une action. Ce peut être un input, balise a ou un div, un span…Et surtout il inhibe le “href” d’une balise <a>.

De ce fait il font prévoir une technique de dégradation progressive (gracefull degradation)

Conclusion

Ajax est un incontournable du web. Il permet de véritable avancé dans l’ergonomie, dans l’efficience. Mais il y a des zones où il faut faire très attention dans son utilisation.

De manière générale

• il faut utiliser Ajax de manière parcimonieuse (pas partout, pas tout le temps, bref ne pas être un intégriste de l’ajax)
• indiquer lorsque une info est mise à jour via Ajax (clignotement, image, couleur, son)
• faire attention en terme de programmation (le synchrone est plus facile)
• utiliser Ajax non par mode mais par réel soucis de performance et/ou d’intérêt fonctionnel (auto-completion….)
• Se mettre à la place des robots des moteurs de recherche et prévoir des informations additionnelles ou une dégradation progressive afin de leur permettre d’avoir de quoi se mettre sous la dent
  • mettre les vraies adresses dans une balise <a> quitte à les supprimer via Javascript afin que l’on puisse faire de l’Ajax.