Développement Ajax : quelques clés pour une architecture javascript moderne

A l'heure où Ajax se répand au point d'envahir bon nombre des offres d'emploi de certains sites spécialisés et où de plus en plus de code repasse côté client, il devient nécessaire de se poser quelques questions sur l'architecture des développements Javascript.

Ces questions, les voici :
1- Utilisera-t-on (ou non) des frameworks intégrant serveur et client (backbase, GWT, webdev) ?
2- Le javascript sera-t-il situé uniquement côté client ou alors sera-t-il aussi généré par le serveur ?
3- Quelles librairies js utiliser côté client ? comment les articuler ?
4- Utilisera-t-on (ou non) Javascript comme un vrai langage objet avec "espaces de nom" et "classes" héritant les unes des autres ?
5- Quelles couches distinguer dans le développement Javascript et comment les articuler à la fois entre elles et avec les couches serveur ?
6- Quelles bonnes pratiques architecturales suivre de manière générale en js ?

Je vous donne rapidement MES réponses à ces questions... je tranche assez franchement pour mieux faire naître le débat !

1- Un framework Ajax côté serveur ?
Non, déléguer la reponsabilité du client à une technologie serveur est une mauvaise idée. Ca vous permettra peut-être un temps d'être plus productif, mais certainement pas sur la durée. Pour traiter les problèmes côté client, il est bien entendu beaucoup plus efficace d'utiliser une technologie cliente... même si ça peut paraître pénible à certains de se (re)mettre à Javascript, XHTML et aux css.

2- le JS côté client uniquement ?
Oui, autant que cela est possible... les avantages sont nombreux : séparation des couches applicatives claire, performance, productivité du développement sur le long terme.

3- quelles librairies JS ?
Une et une seule bonne librairie "noyau" (prototype ou JQuery sont mes premiers choix mais il n'est pas interdit de regarder ailleurs... en faisant très attention !) qu'il faut utiliser à fond : plus question par exemple d'utiliser prototype uniquement pour Ajax.Request ! La librairie noyau doit servir à la gestion des événements, la manipulation du DOM et aux appels AJAX dans l'ensemble de votre code.
Si vous avez bien choisi la librairie noyau, les éléments qui viennent s'y raccrocher (en particulier les effets graphiques évolués) ne devraient pas vous manquer.

4- des classes et des espaces de nom ?
Oui, bien sûr ! Même si javascript n'offre pas ces possibilités de manière native, il est tout à fait possible de les simuler et de tirer tous les bénéfices que l'on connaît depuis longtemps côté serveur à ces pratiques. Prototype en est un excellent exemple.

5- quelles couches côté JS ?
A l'heure où le stockage local devient une réalité dans les applications Ajax, établir une véritable couche d'accès aux données paraît de plus en plus incontournable : lire à ce sujet le très bon brief de l'équipe de Google Gears.
De manière générale, les couches côté JS vont ressembler de plus en plus à celles que l'on connaît habituellement "server side" : données / accès aux données / logique métier / interface. Tout le défi va être d'articuler cela avec les responsabilités attribuées au serveur : rien d'infaisable en réalité.

6- les bonnes pratiques architecturales JS ?
Ce ne sont évidemment pas tout à fait les mêmes que sur une technologie serveur : Javascript est un langage bien particulier (mais pas un sous-langage !) et le client riche pose des problèmes très spécifiques. Cependant, ça n'empêche pas, bien au contraire, d'avoir recours à des motifs de conception pour bien aborder et résoudre la plupart des problèmes : un petit tour sur Ajax Patterns sera utile à toute personne qui se pose de bonnes questions sur le sujet.

Allez-y, réagissez, indignez-vous, lancez moi des fleurs, insultez moi ! Ces questions-là sont capitales, alors il vaut mieux en parler...

Ext, OpenAjax : la planète Ajax s'organise

Un des doux rêves que caresse plus ou moins consciemment l'intégralité des développeurs Ajax est de disposer de librairies javascript organisées, modulables et répondant à des normes limitant au maximum les problèmes de compatibilité. Bien loin de penser qu'un tel Graal puisse être atteint à court terme, c'est avec un plaisir non dissimulé que je vous fait part du lancement de la bêta de Ext.

Ext est une librairie qui, à son origine, étendait le noyau de Yahoo UI pour mettre à disposition un certain nombre de widgets bien pratiques (calendriers, onglets, sliders...). Bien architecturée, la librairie a pu être rapidement adaptée pour se passer du noyau YahooUI, pour le remplacer par l'excellent JQuery ou encore le célèbre couple Protoype + scriptaculous.

Ext possède à ce jour une vingtaine de widgets d'une grande qualité, mais aussi et surtout une excellente documentation tirant pleinement partie de ext. Au delà de la performance, c'est l'effort de généricité/modularité des auteurs de cette librairie qui me rend optimiste pour l'avenir.

Cette démarche me semble s'inscrire dans un mouvement plus général de rationalisation du petit monde Ajax. Autre fait révélateur de ce mouvement, l'OpenAjax Alliance est en train de sortir de l'impasse dans laquelle je pensais qu'elle se trouvait :
- Google et Microsoft l'ont récemment rejointe
- l'OpenAjax Hub, un ensemble de spécifications à respecter pour les librairies Ajax produites
par les membres de l'Alliance, est sur le point de sortir en version 1.0

Il est assez heureux de voir ajax arriver à maturité à l'heure où les alternatives RIA se multiplient et où les éditeurs se donnent un mal fou à faire venir les développeurs ajax vers leur technologie.

AJAX, JSON et BISON au secours de la bande passante

Dans la formidable époque que nous sommes en train de vivre, le web subit une révolution discrète et pourtant cruciale au royaume de "l'expérience utilisateur" : les applications du web ont en effet maintenant plus que jamais les moyens de réduire considérablement la bande passante utilisée.

Or sous des dehors techniques, cet aspect du web 2.0 est tout sauf un problème de geek :
- pour l'utilisateur, moins de données à faire transiter signifie une meilleure réactivité de l'application à ses différentes actions.
- pour le financier, moins de bande passante entraîne une baisse qui peut être significative des coûts de structure... en particulier dans le cas d'une montée en charge rapide de l'application.

Comment concrètement s'opère cette baisse de consommation ?
- Dans le passé, ce fut AJAX qui permit d'économiser des rechargements de page complets à chaque fois que des appels serveur sont nécessaires.
- Aujourd'hui, c'est JSON (si il est bien utilisé) qui diminue de manière considérable la taille des réponses renvoyées par les serveurs suite à une requête AJAX.
- Demain, ce sera peut-être quelque chose comme BISON (qui n'est qu'une expérimentation) d'une part et le stockage client massif d'autre part qui permettront d'optimiser encore un peu plus le flux d'information transitant entre le serveur et le client.