vendredi, juin 29

AIR (ex Apollo) / Google Gears : même combat !

Je ne suis pas de ceux qui tracent une ligne rouge entre ce que certains appellent RDA (pour Rich Desktop Application qui s'exécutent hors navigateur) et les RIA (Rich Internet Application qui s'exécutent dans un navigateur).

Les marchés, les technologies, les contenus et les possibilités de ces 2 familles sont trop proches pour les considérer comme véritablement distinctes... Je continuerai donc ici de parler de plate-formes RIA pour des technos aussi différentes que WPF, AIR, Ajax, Flash, Silverlight, XUL, Java ou les plate-formes de widgets : j'excluerai par contre OpenLazlo ou Flex de cette terminologie dans la mesure où ils ne sont que des technologies serveur (pour plate-forme RIA, certes) et non des runtimes.

Cette proximité entre des technologies au prime abord assez différentes me paraît d'ailleurs chaque jour un peu plus évidente. Dernier exemple en date avec quelques essais menés sur Google Gears d'une part et AIR d'autre part.

Ces 2 technos partent d'un même principe : l'inertie des habitudes de développement web est telle, la concurrence entre nouvelles technos si féroce, que pour s'imposer il vaut mieux accomplir une révolution douce. Et quel est le discours de ces gentils révolutionnaires ?

- Continuez à utiliser vos technos de développement web : Ajax, Flash... ce sont de bonnes technos, et vous avez encore pas mal de clients à satisfaire avec.
- Continuez à développer des sites/applications que l'on peut visiter avec un simple navigateur : c'est une avancée majeure du web qu'il ne faut pas perdre.
- Allez plus loin sur certaines fonctionnalités avec les clients/utilisateurs qui le souhaitent grâce à nos technologies : mode offline, accès aux ressources systèmes.
- Soyez rassurés, nos technologies sont convergentes : Javascript, XML, SQLite...

Et vous savez quoi ? C'est vrai ! Il n'agit pas simplement d'un discours commercial comme on en a beaucoup entendu ces dernières années. Les quelques essais que nous avons faits mes collègues et moi, nous ont montré que pour une même application les implémentations AIR et Gears sont très proches... et, ça, c'est une très bonne nouvelle, vous ne trouvez pas ?

mardi, juin 26

Traduction de "What is web 2.0" : nouvelle release

Avec l'aide de Christelle, collaboratrice de passage, j'ai pu compléter les quelques morceaux qui manquaient à la version française de "What is web 2.0", l'exposé de la brillante vision de Dale Dougherty et Tim O'Reilly. Tout cela a été mis sur le site de la jeune et sympathique société de votre serviteur. Les liens de la version originale ont également été ajoutés et quelques bourdes corrigées.

Ce nouveau petit plongeon dans cet article fondateur a d'ailleurs été pour moi l'occasion de constater que près de 2 ans après, il garde encore toute sa fraîcheur et sa pertinence comme si ses grands principes étaient intemporels...

Pour les connaisseurs, quelques raccourcis vers les nouvelles parties traduites (ce sont les pavés latéraux) :
Une plateforme gagne contre une application à tous les coups
L'architecture de participation
Une thèse de l'investissement dans le Web 2.0
Les modèles de conception du Web 2.0

samedi, juin 23

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

jeudi, juin 14

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 !

samedi, juin 2

Google Gears... une révolution ?

Je ne pouvais décemment pas passer à côté de la sortie du projet sur Google Gears après tous mes articles sur le web offline. Faute de temps, il va néanmoins me falloir faire (très) court sur le sujet pour le moment.

Google Gears arrive en 3 morceaux : workerpool (une solution pour faire tourner le JS hors du runtime habituel du navigateur), localserver (un mini-serveur web pour page stockées en cache) et Database (une base de données SQLite munie d'une API Javascript).

Cela n'a pas grand chose à voir avec l'approche de Dojo Offline Toolkit, mais c'est tout de même très excitant : cette solution est même techniquement à ce point séduisante qu'elle pourrait à terme être inclue dans les systèmes d'exploitation et/ou les navigateurs. On parie ?