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...

Google Gears : tout l'intérêt de WorkerPool en une démo

Je reviendrai très prochainement plus en détail sur ce qui risque de changer Google Gears pour les utilisateurs, les développeurs et les entrepreneurs du web... mais je ne résiste pas dans l'attente au plaisir de vous faire partager une petite démo qui montre tout l'intérêt d'une partie de Gears qui n'a, semble-t-il, pas été apprécié à juste valeur par nombre de lecteurs : WorkerPool.

En effet, si les atouts d'un serveur et d'une base de données accessibles en JS sur le poste client paraissent assez évidents, le concept du workerpool l'est moins. Rappelons-le. Le workerpool permet de faire fonctionner des morceaux de javascript dans un processus différent des autres. Ce n'est pas vraiment un "thread", mais ça a le même goût : les processus créés ne se bloquent pas les uns les autres et sont traités de manière efficace par le système d'exploitation.

Pas convaincu ? Après avoir installé Gears, essayez la démo suivante avec workerpool et sans workerpool... on reparlera ensuite des limites de performance de javascript !

Tamarin : le futur de Javascript par Adobe et Mozilla

A une époque où le web est la technologie dominante et Javascript son nouveau ressort, on comprend aisément que ce qui peut révolutionner Javascript peut changer beaucoup de choses par ailleurs.

Javascript, je l'ai déjà dit à de nombreuses reprises est bourré de défauts, et parmi ceux-ci, ses performances calamiteuses n'est pas le moindre. Or, à l'heure où tout est bon pour faire du javascript, cela peut s'avérer très pénible. Pénible au point que notre web 2.0 se surprend à reprendre des couleurs 1.0, lorsque toutes ces jolies fonctions ajax qui facilitent la vie de l'utilisateur se mettent à patiner à un point invraisemblable. Pire : certaines applications (comme la 3D) resteront hors de portée de JS tant que ces limitations ne seront pas levées.

Une fois encore, le problème de vient pas vraiment de javascript en tant que langage mais plutôt des moteurs d'exécutions embarqués dans les différents navigateurs... et c'est précisément là que Tamarin intervient.

Tamarin est le nom de code donné par Adobe à son projet de moteur ecmascript (javascript si vous préférez, la nuance est subtile) destiné à le booster significativement en le compilant Just In Time en code machine (façon Java ou .Net) : une excellente idée... Et Adobe ne s'est pas arrêté en si bon chemin, puisqu'en novembre dernier, le code du projet a été ouvert et que le leadership du projet confié à la fondation Mozilla.

Résultat ? Les applications web de demain pourront être autrement plus exigeantes que les bricolages d'aujourd'hui ! Pour être plus précis, sachez que FlashPlayer 9 utilise déjà Tamarin et Firefox devrait l'intégrer en 2008 (à l'occasion du passage vers Javascript 2). C'est aussi pour cela qu'à contre-courant de l'actualité, je choisis de parler aujourd'hui de ce projet : parce qu'il crédibilise encore un peu plus Ajax et Flash face aux alternatives RIA montantes.

La 3D, le web et javascript

La 3D sur le web est un vieux rêve qui semble être repoussé chaque jour :
- VRML n'a jamais vraiment pris
- X3D son successeur désigné, ne semble pas vraiment prendre la suite
- aucune solution de remplacement n'a réellement émergé

Une fois encore, des hackers javascript se sont retroussé les manches pour parvenir à une solution à l'aide de le nouvelle balise HTML "canvas" (malheureusement inconnue de nos amis de chez Microsoft)... et à ma grande surprise, ça marche ! Du moins, de temps en temps.

Quelques exemples, parce que ça vaut quand même le coup d'oeil :
- une démo d'un moteur de rendu (qui fait ce qu'il peut)
- un jeu en 3D (injouable)
- une démo de voiture avançant une route improbable

Bon, en attendant que tout ça progresse, Flash et WPF semblent pour le moment les alternatives les plus raisonnables... à moins que vous n'ayez une meilleure idée ?

Firebug : quand l'exceptionnel se fait indispensable

Firebug 1.0 est sorti en début d'année, et si vous développez un peu, je vous encourage vivement à le mettre à jour / réessayer / découvrir si ce n'est pas encore fait. Le meilleur ami du développeur Ajax fait maintenant tout ce qu'il faut pour vous aider au quotidien :
- inspecter et analyser le code HTML élément par élément
- visualiser les styles de vos pages aisément
- voir toutes les requêtes HTTP dans le détail
- débuguer Javascript mieux que jamais
- examiner les objets DOM simplement

Et beaucoup de petites choses pratiques (messages console, débugage sous IE !) que je vous laisse découvrir en font maintenant un outil à la fois fiable et incontournable... qui nous rend impatients d'en découvrir la prochaine version !