Ajax: questions et réponses

La FAQ originelle par Jesse James Garrett

Traduction française de la partie questions et réponses par Denis Sureau le 26 Octobre 2006.

13 Mars 2005: Depuis que nous avons publié l'essai de Jesse, nous avons reçu une énorme correspondance de lecteurs avec des questions sur Ajax. Dans ce Q&R, Jesse répond à quelques interrogations les plus fréquentes.

Q. Est-ce que Adaptive Path a inventé Ajax? Est-ce Google? Est-ce que Adaptive Path aide Google à réaliser les applications Ajax?

R. Ni Adaptive Path ni Google n'ont inventé Ajax. Les produits récents de Google sont simplement des exemples d'applications Ajax qui sont le plus remarquables. Adaptive Path n'a pas été impliqué dans le développement des applications Ajax de Google, mais il nous est arrivé de réaliser des travaux en Ajax pour quelques uns de nos autres clients.

Q. Adaptive Path vend-t'il des composants Ajax ou exploite-t'il le nom de marque? Ou puis-je le télécharger?

R. Ajax n'est pas quelque chose que vous puissiez télécharger. C'est une approche, un mode de pensée quand à l'architecture des applications web qui utilise certaines technologies. Ni le nom Ajax ni l'approche ne sont propriété d'Adaptive Path.

Q. Ajax est-il juste un autre nom pour XMLHttpRequest?

R. Non. XMLHttpRequest est seulement une partie de l'équation Ajax. XMLHttpRequest est le composant technique qui rend possible la communication asynchrone avec le serveur; Ajax est notre nom pour l'approche d'ensemble décrite dans l'article, qui se fonde non seulement sur XMLHttpRequest, mais sur CSS, DOM, et autres technologies.

Q. Quand avez-vous éprouvé le besoin de donner un nom à cela?

R. J'avais besoin de pouvoir utiliser quelque chose de plus court que "JavaScript+CSS+DOM+XMLHttpRequest asynchrones" lorsque je discutais de cette approche avec les clients.

Q. Des techniques pour la communication asynchrone avec le serveur existent depuis des années. Qu'est-ce qui fait que Ajax soit une "nouvelle" approche?

R. Ce qui est nouveau est l'utilisation prédominante de ces techniques dans les applications du monde réel pour changer le modèle fondamental d'interaction sur le Web. Ajax prend la main maintenant parce que ces technologies et la compréhension par l'industrie de la façon de les déployer ont mis du temps à se développer.

Q. Ajax est-il une plateforme technologique ou est-ce un style architectural?

R. Il est les deux. Ajax est un ensemble de technologies utilisées conjointement d'une façon particulière.

Q. Pour quelles sortes d'applications Ajax convient-il le mieux?

R. Nous ne le savons pas encore. Comme c'est une approche relativement nouvelle, ce que nous savons des domaines ou Ajax s'applique le mieux en est encore au stade de l'enfance. Quelquefois le modèle d'application web traditionnel est la solution la plus appropriée à un problème.

Q. Cela signifie-t'il qu'Adaptive Path est anti-Flash?

R. Pas du tout. Macromedia est un client d'Adaptive Path, et nous avons été supporters de la technologie Flash depuis longtemps. Avec la maturation d'Ajax, nous nous attendons à ce que Ajax soit la meilleure solution pour un problème particulier, et quelquefois ce sera Flash la meilleure solution. Nous nous intéressons aussi à l'exploration des façons dont les technologies peuvent être mixées (comme dans le cas de Flickr, qui utilise les deux).

Q. Ajax a-t'il une accessibilité suffisantes ou des limitations dans la compatibilité avec les navigateurs? Les applications Ajax désactivent-elles le bouton retour? Ajax est-il compatible avec REST? Y-at-'il des considérations de sécurité avec le développement en Ajax? Peut-on faire des applications Ajax qui fonctionnent avec les utilisateurs qui ont désactivé JavaScript?

R. La réponse à toutes ces questions est "peut-être" De nombreux développeurs ont déjà travaillé sur la façon d'obvier à ces soucis. Nous pensons qu'il faut travailler encore pour déterminer toutes les limitations d'Ajax, et nous nous attendons à ce que la communauté de développement Ajax mette au jour plus de problèmes avec le temps.

Q. Quelques uns des exemples Google que vous citez n'utilisent pas du tout XML. Ai-je à utiliser XML et/ou XSLT dans une application Ajax?

R. Non. XML est le moyen le plus abouti pour obtenir des données vers et par un client Ajax, mais il n'y à pas de raison pour que vous ne puissiez pas obtenir les mêmes effets en utilisant une technologie comme JavaScript Object Notation ou tout moyen similaire pour structurer les données à échanger.

Q. Les applications Ajax sont-elles plus faciles à développer que les applications web traditionnelles?

R. Pas nécessairement. Les applications Ajax impliquent inévitablement que l'on exécute du code JavaScript complexe sur le client. Faire que qu'un code complexe soit efficace et exempt de bogues n'est pas une tâche à prendre à la légère, et de meilleurs outils de développement et cadres d'applications seront nécessaires pour nous aider à relever ce challenge.

Q. Les applications Ajax fournissent-elles toujours un résultat meilleur que les applications web traditionnelles?

R. Pas nécessairement. Ajax fournit aux réalisateurs d'interaction plus de flexibilité. Toutefois, plus vous avez de pouvoir, plus vous devez prendre de précautions en l'utilisant. Nous devons prendre garde à utiliser Ajax pour améliorer ce qui se passe pour l'utilisateur de nos applications, et non pas le dégrader.

Jesse James Garrett est le directeur de User Experience Strategy et un fondateur de Adaptive Path. Il est l'auteur du livre très largement référencé The Elements of User Experience.


Première partie: Une nouvelle approche pour les applications web.

Creative Commons License

Le document original est sous licence Creative Commons License. Certains liens ont été changés pour des liens sur des sites en français.
La licence de cette traduction française est la suivante: Vous pouvez imprimer ce document et le diffuser sans restriction, sous réserve que le nom de l'auteur et toutes indications légales soient inchangées. Vous ne pouvez pas mettre ce document sur un autre site web: mettez plutôt un lien sur cette page.