Non, non, Ajax n’est pas seulement un nettoyant pour sol, mais c’est aussi un outil indispensable pour améliorer l’expérience utilisateur d’un site web.
D’accord, c’est un outil puissant mais il faut être rigoureux.
Pourquoi ? Car nous avons d’un coté toutes les requêtes serveur (faites en php par exemple) et de l’autre les appels client (Javascript/Ajax) pour avoir une page dynamique au plus haut point (Un fichier Javascript qui fait appel à un fichier PHP qui lui envoie ses requetes au serveur).
Pratique ? Je ne sais pas, mais il est certain que si on ne s’organise pas un minimum dans son code, on s’y perd vite.
Je vous conseillerai de suivre le modèle MVC du côté serveur (PHP), un contrôleur qui vérifie quelles requêtes Ajax sont envoyées, une classe pour chaque table et la vue où se trouve votre JS (et AJAX). (D’ailleurs vous pouvez aussi séparer votre JS de votre vue en la mettant dans un fichier à part, là je pense que vous aurez atteint le must de la rigueur.
Recharger sa page, pour quoi faire ? C’est vrai qu’avec les librairies telles que Jquery, la génération d’une page en Javascript (JS pour simplifier) n’a jamais été aussi simple (je ne dis pas que c’est simple mais juste plus simple qu’autrefois). Bref, le gain de temps peut être considérable (pour le client) ! Donc pourquoi s’embêter à recharger sa page et ne pas (re)générer sa page en JS pour que cela soit plus fluide pour l’utilisateur ?
Tout simplement car c’est très mauvais pour le référencement, comme me le dit si bien mon professeur de référencement « un produit, une page », sinon votre site sera très mal référencé. Dites-vous bien que l’algorithme de Google n’exécute pas le JS, donc imaginez que tout est généré depuis un script : référencement réduit à néant. Et si pas de référencement, pas d’utilisateur, mais après tout, si vous êtes Apple , le référencement n’est pas un soucis !
Attention aux requêtes trop longues ! En effet, m’étant lancé dans l’AJAX depuis peu, j’ai codé, codé, codé sans pour autant optimiser mes requêtes SQL . En développant sur sa propre machine, ça ne se voit peut-être pas mais lors de la mise en (pré)production, on s’aperçoit en un rien de temps la perte de vitesse et de fluidité du site. Et quand le script mets 2-3 secondes à s’exécuter, je peux vous dire que l’Ajax perd toute son utilité !
Donc OPTIMISEZ vos requêtes, regardez sur le net, MySQL a réalisé une doc sur cette partie. (C’est par mysql-optimization, c’est par ici)
Donc, Ajax c’est bien, mais il faut l’utiliser à bon escient ?
Pour ma part, je dirais que oui, c’est un grand atout et niveau expérience utilisateur c’est top car vous avez beaucoup moins de rechargement de page, c’est quand même plus sympa. (Exemple des lights box pour l’ajout/modification d’item).
Le site en full-JS/Ajax est tout même à bannir, une page pour tout votre site, NON, le référencement s’en ferait ressentir.
Après, certains conseillent que le site soit fonctionnel pour ceux qui n’auraient pas activé le JavaScript sur leur navigateur.
Mais sérieusement, qui de nos jours le désactive ? Enfin, non mais quoi, est-ce vraiment possible ? Tant pis pour eux, non ? (ça ne reste que mon avis).
Bref, pour ma part, je m’en sers depuis deux mois et j’avoue utiliser l’Ajax couplé à PHP dans tous mes nouveaux projets. Ceci dit, d’après ce que j’ai pu lire, Ruby on Rails se marie très bien à Ajax. (Pour l’instant j’en suis qu’au stade de débutant en Ruby on Rails mais j’espère vite pouvoir vous en dire plus.)
Si vous avez des questions, je suis tout ouïe.