testé et désapprouvé : mais uniquement sous sa forme actuelle, l'avenir reservera peut-être des surprises (mais j'en doute...).
Attention: la suite de mon commentaire ne couvre que l'utilisation que j'ai faite d'"ajax". Je suis bien concient qu'il y a des cas de figure assez courants (mais tout de même particuliers) pour lesquels un petit coup d'ajax bien placé apporte réellement un gros plus.
Au chapitre des griefs : l'objet xmlhttprequest est : difficile à créer (bien que le même petit bout de code ce copie colle un peu partout et voyage sur la toile :). Difficile à utiliser : divers bugs d'IE et de Moz rendent la programmation extremement fastidieuse. Remarquez c'est la même came que le javascript en général question compatibilité entre navigateurs.
Mais ce n'est pas tout : une fois xmlhttprequest maitrisé (une bonne journée mini pour découvrir pas mal de problème et autant de moyen différents de les contourner) (et on se rend bien souvent compte dans un deuxième temps que ce n'est parce qu'il marche souvent pas trop mal qu'il est utilisé correctement au sein d'un code et ne posera jamais de problème), il reste encore à faire un bon gros^W énorme coup de DHTML pour faire de la modif dynamique sur un langage de description qui n'a jamais été conçu pour ça. Ce qui en résulte est d'une extrème lourdeur et d'un très grande complexité. D'autant plus qu'avec une conception récente l'html complet d'une page est souvent assez petit et que dans bien des cas (mais pas tous ! certes) un rechargement complet serait très efficace et simplifirait beaucoup la conception.
Enfin ajax a tendance à éclater les différents aspect d'un logiciel web-based et à multiplier le nombre de composants et donc d'interfaces necessaire à sa réalisation.
Alors bien sûr on couvre quand même un énorme besoin. Mais à quel prix ? Pour se faciliter la tache on peut rajouter un framework pour abstraire tout ça et éviter les petits désagrement (enfin le "on peut" est assez relatif parce que bien souvent, "on peut" pas :). Mais jusqu'à quand continura-t-on à empiler les couches ? Enfin tous les besoins ne sont pas couvert (exemple: push d'un evenement en provenance du serveur impossible, necessité de faire faire un polling par le client, beurk :/)
Ma conclusion et qu'il reste à inventer un concurrent à l'html et toutes les techno sous-produit de l'html qui gravitent autour pour concevoir des interfaces type client leger vraiment dynamiques et efficaces, déployables partout dans le monde avec une grande efficacité, un design simple, etc, etc... Malhereusement pour les raisons de backward compatibility et autre habituel, je ne vois ça arriver ni à cours ni à moyen terme. Snif :/
# testé et desapprouvé
Posté par Guillaume Knispel . En réponse au sondage AJAX. Évalué à 7.
Attention: la suite de mon commentaire ne couvre que l'utilisation que j'ai faite d'"ajax". Je suis bien concient qu'il y a des cas de figure assez courants (mais tout de même particuliers) pour lesquels un petit coup d'ajax bien placé apporte réellement un gros plus.
Au chapitre des griefs : l'objet xmlhttprequest est : difficile à créer (bien que le même petit bout de code ce copie colle un peu partout et voyage sur la toile :). Difficile à utiliser : divers bugs d'IE et de Moz rendent la programmation extremement fastidieuse. Remarquez c'est la même came que le javascript en général question compatibilité entre navigateurs.
Mais ce n'est pas tout : une fois xmlhttprequest maitrisé (une bonne journée mini pour découvrir pas mal de problème et autant de moyen différents de les contourner) (et on se rend bien souvent compte dans un deuxième temps que ce n'est parce qu'il marche souvent pas trop mal qu'il est utilisé correctement au sein d'un code et ne posera jamais de problème), il reste encore à faire un bon gros^W énorme coup de DHTML pour faire de la modif dynamique sur un langage de description qui n'a jamais été conçu pour ça. Ce qui en résulte est d'une extrème lourdeur et d'un très grande complexité. D'autant plus qu'avec une conception récente l'html complet d'une page est souvent assez petit et que dans bien des cas (mais pas tous ! certes) un rechargement complet serait très efficace et simplifirait beaucoup la conception.
Enfin ajax a tendance à éclater les différents aspect d'un logiciel web-based et à multiplier le nombre de composants et donc d'interfaces necessaire à sa réalisation.
Alors bien sûr on couvre quand même un énorme besoin. Mais à quel prix ? Pour se faciliter la tache on peut rajouter un framework pour abstraire tout ça et éviter les petits désagrement (enfin le "on peut" est assez relatif parce que bien souvent, "on peut" pas :). Mais jusqu'à quand continura-t-on à empiler les couches ? Enfin tous les besoins ne sont pas couvert (exemple: push d'un evenement en provenance du serveur impossible, necessité de faire faire un polling par le client, beurk :/)
Ma conclusion et qu'il reste à inventer un concurrent à l'html et toutes les techno sous-produit de l'html qui gravitent autour pour concevoir des interfaces type client leger vraiment dynamiques et efficaces, déployables partout dans le monde avec une grande efficacité, un design simple, etc, etc... Malhereusement pour les raisons de backward compatibility et autre habituel, je ne vois ça arriver ni à cours ni à moyen terme. Snif :/