AJAX -- le DHTML associé à des requètes HTTP -- permet aux sites web de rendre les pages dynamiques. Je ne parle pas de dynamisme côté serveur, celà est le pré carré de PHP, Ruby ou autre. Non, je parle du côté client, votre browser.

Sur ce site, vous avez maintenant accès à une fonctionalité de " recommandation ", où vous pouvez donner votre avis en attribuant des étoiles à chaque article.

Lorsque vous sélectionnez un nombre détoiles, la page -- via Javascript -- envoye une requète HTTP au serveur, qui prend note de votre recommandation, et retourne le nouveau rang global de l'article, une fois votre note ayant été prise en compte.

Ce qui est interessant ici, c'est que la page elle-même n'est pas rechargée depuis le serveur, comme le ferait un site classique ; elle est simplement modifiée localement sur votre browser, assez discrètement ( faites-en l'expérience ! ). Ainsi vous obtenez un site dont le comportement se rapproche un peu plus d'une application classique.

On peut donc trouver de nombreuses applications à Ajax. Et même imaginer de baser un site entièrement dessus -- par exemple, allez voir Google suggest.

Récemment, j'ai implémenté un système de méssagerie instantanée en Ajax. Ce type d'application semble parfaitement adapté. La partie cliente lance régulièrement des requètes HTTP au serveur afin d'obtenir les nouveaux messages reçus, et les affiche dans la page.

Bien qu'interessante, cette technique conduit peu à peu à considérer les applications Web, non plus comme de larges livres électroniques ouverts, que l'on feuillette à loisir, mais plutôt comme de " vrais " applications, plus réactives, plus interactives.

Outre le changement de nature que cela provoque, une des incidences non négligeable est l'accroissement de la bande passante nécessaire à l'animation de ces sites.

Dans mon cas, la messagerie instantannée provoque un accroissement considérable de la bande passante consommée. Je parle là non pas de quelques pourcents, mais bien d'une multiplication de près de cent fois !

Alors, comment équilibrer ce surcoût ? Est-ce la bonne voie où aller ?

AJAX -- DHTML associated to HTTP requests -- makes it possible for sites to have genuine dynamic pages. I don't say dynamic for the server side, this is already the purpose of PHP, Ruby or whatever. No. I do speak about the client side, your browser.

On this site, you've been provided with a "recommend" feature; you can rate any stars you think an article is worth.

When you click on a select box, by using Javascript, the page sends an HTTP request to the server, which in turn, stores your recommendation. Once taken into account, the server send the new rating back to the client. The browser displays it.

What's interesting here, is that the page itself is not reloaded from the server as most of the sites would do. The page is siply locally updated from within your browser (give it a try!). This way, you really end up with a more interactive experience, somthing closer to a classic desktop application.

One can find a lot of features that could take advantage of Ajax. One can even think of a site based exclusively on this technology -- see Google suggest for instance.

I recently implemented an instant messaging system with Ajax. This kind of application is perfect for it. The client side is polling the server with HTTP request to fetch any incoming messages, and then, displays them on screen.

Though interesting, this make web sites sillently ressembling to classic desktop app, losing their book-like very nature; you do not longer turn pages, and get more interactivity.

Additionally, it's worth to note that Ajax is something rather bandwith-consumming. More interactions, more bandwith.

For me, my IM required a 100 fold bandwidth increase!

In conclusion, we have to find out how to balance the bandwidth cost increase. Then, is it the right way to go?