5 idées reçues sur les technos Web 2.0

La révolution du Web2.0 s’est accompagnée d’un saut technologique dans le développement d’applications. Les applications Ajax relèguent les sites dits “1.0″ aux oubliettes avec une interactivité et une présentation jamais vue sur Internet. Faut-il pour autant considérer Ajax, Ruby On Rails ou équivalent sur PHP, comme des impératifs de toute nouvelle application Web? Voici 5 idées techniques sur le Web2.0 qui méritent discussion:

Idée n°1: Les applications AJAX sont plus interactives et performantes

Premièrement, la tonne de code Javascript nécessaire pour faire fonctionner une application Java rend le temps d’accès initial beaucoup plus long que pour une page standard (à images et contenus externes équivalents).

Deuxièmement, une requête Ajax nécessite toujours un aller-retour serveur, et dans la majorité des cas, toujours une requête en bases de données. En conséquence, on économise seulement le temps de chargement de la page et le temps de rendu du browser. Effectivement, la suppression du temps de rendu donne une impression d’interactivité accrue et le temps de chargement du code HTML peut parfois êtreassez conséquent. Mais pour n’importe quelle autre requête avec un temps de traitement supérieur au rechargement et rendu, il y a quand même un délai à prévoir. Le problème en Ajax est qu’il faut maîtriser l’utilisateur puisque l’interface n’est pas bloquée pendant l’exécution de la requête (un seul utilisateur pourrait alors provoquer un blocage serveur en s’énervant sur l’application). C’est surtout vrai pour tous les événements liés à une frappe clavier (auto-complétion par exemple) ou des mouvements de souris: l’utilisateur peut à lui seul excéder les capacités d’une application dimensionnée de manière “classique”. Conséquence: il faut arbitrer entre performances serveur et interactivité utilisateur, beaucoup plus que dans le cas d’une application classique. Pour les connaisseurs, l’utilisation massive d’Ajax au sein d’une page a tendance à réduire très fortement le think time, connu pour avoir une influence majeure sur les capacités d’une infrastructure web.

Deuxième point souvent oublié, l’exécution de code Javascript dans les navigateurs est parfois (très) lente, au point de provoquer des ralentissements significatifs du browser. C’est en partie lié à la gestion d’un grand nombre d’événements Javascript simultanés. C’est aussi lié à la perception de l’utilisateur: certaines techniques de présentation Ajax visent à transformer des requêtes asynchrones en interactions synchrones. Dès que le délai de réponse pour chaque requête augmente, l’utilisateur perçoit un ralentissement.

Last but not least, Javascript est un langage très complet, avec OOP, closures, first-order functions et est donc sujet, comme les autres, à des problèmes de fuites de mémoires. Sur certaines versions de Firefox (même pas d’IE), une fenêtre avec Netvibes peut peser jusqu’à 190-200 Mo. Malheureusement, tracer et corriger ces fuites demande une expérience que la plupart des développeurs n’ont pas et des outils qui ne sont pas forcément non plus très simples à utiliser.

Idée n° 2: Les applications Web 2.0 sont plus ergonomiques.

Le fait d’avoir plus d’interactions avec le serveur et des techniques Javascript plus avancées permet de proposer des choix ergonomiques proche d’applications de bureau. Ce n’est pas parce que l’on peut, que l’on doit systématiquement caser tel ou tel gimmick dans son application.
Quelques exemples et/ou situations:

Drag & drop.

La métaphore du glisser-déplacer d’articles dans le caddie ne tient pas la route. C’est gadget et c’est infiniment moins performant que de cliquer sur “Ajouter à mon panier”. D’ailleurs, si au supermarché il suffisait de toucher (voire de montrer) l’article pour qu’il soit dans le caddie, ça serait plus pratique, non? Dans la plupart des cas, le drag & drop n’est de toute façon pas nécessaire. C’est plus de la poudre aux yeux que réellement utile pour l’utilisateur. Le seul cas d’application que je trouve pertinent est lorsque l’on veut demander à un utilisateur de réordonner des éléments.

Edition en place (voir exemple ).

Je trouve ça en général sympa et pratique comme mode d’édition. Le seul défaut majeur de cette technique est qu’il faut que l’utilisateur pense à passer sa souris sur l’élément pour l’éditer (ou alors il faut lui dire). C’est plutôt bizarre finalement puisque la plupart des textes sur le Web ne sont pas éditables et quand il y a quelque chose d’éditable, on le voit clairement (champ de saisie).

Les effets visuels

Ce n’est pas propre au Web en particulier. Les effets visuels doivent être réduits au strict minimum car ils entravent l’utilisation de l’application. D’ailleurs les applications de Google, souvent citées comme références, n’utilisent pas du tout d’effets visuels (tout au plus des effets de transparence pour simuler une boîte de dialogue modale)

Idée n° 3: Les langages du Web2.0, et donc du futur, sont Ajax, Ruby on Rails et PHP

Premièrement Ajax n’est pas un langage mais un terme marketing collé sur une combinaison de technologies dont le coeur existe depuis 1999. Bizarrement, l’usage de cette techno a repris que très récemment, projetée sous les feux de la rampe par Gmail. Derrière le terme Ajax, il y a une multitude de techniques et de conventions mais aucune de définitive. C’est bien le problème, on peut plus ou moins tout faire (sauf de l’upload de fichiers) et donc il y a beaucoup de solutions mal architecturées voire pas architecturées du tout. Autre problème majeur: la majorité de l’interaction est déportée sur le poste client et est donc gérée via Javascript. Or, Javascript est notoirement peu maintenable (la plate-forme n’intègre pas la notion de documentation du code par exemple) et il est très difficile de trouver des conventions uniformes pour le code Javascript.

Quand aux langages stars du Web2.0: Ruby on Rails a malheureusement des soucis de performances sur des environnements de production. Le problème vient principalement d’ActiveRecord, la solution d’ORM de RoR qui ne semble pas tenir la charge sur des gros volumes. En dehors de ce point, le framework a l’air plutôt bien fait. Le seul problème est que, RoR est finalement tellement poussé qu’on l’on passe probablement plus de temps à contourner le standard qu’à véritablement développer son application. PHP est reconnu depuis plus longtemps que Ruby pour le développement d’applications Web et il existe de nombreuses très bonnes applications développées en PHP. Mais finalement, cela reste malgré toute une (très bonne) solution de scripting (objet, avec beaucoup de biblothèques utiles, des frameworks MVC, etc.) comme Perl. Là dedans, il n’y a rien de spécifiquement “2.0″. Mais puisque c’est la mode, même la maison IBM intègrera le support de PHP comme plate-forme web 2.0 dans sa prochaine version de Websphere. Comparé à J2EE ou .Net, ces solutions ont des manques évidents: elles ne gèrent pas la notion d’application web, ni les notions de déploiement et d’administration. Bref, là encore, il n’y a pas d’architecture de référence.

Idée n° 4: Construire une application à partir d’un mashup

Je suis le premier à reconnaître l’utilité des mashups, sorte de mix applicatif de plate-formes logicielles librement utilisables. Avec des services comme Google Maps, Geonames, AWS, eBay API ou autres, on peut rapidement créer des applications impressionantes avec assez peu de moyens. J’y mets trois bémols:

Utiliser une API gratuite, c’est être dépendant sans garantie. Aussi louables soient les efforts faits par Google ou Yahoo pour assurer un minimum de compatibilité, on ne peut pas échapper à une inévitable V2 ou V3 qui rend la V1 obsolète. Ceci dit, c’est pas non plus forcément très différent pour les logiciels payants. Par ailleurs, sur ces API, il y a invariablement des limitations du style 1-request-per-second-rule ou une limite sur le nombre d’appels journaliers.

La performance et le niveau de service: Le fait de fédérer des appels depuis plusieurs serveurs différents (chacun correspondant à la plate-forme utilisée) ne peut que diminuer les temps de réponse, que cette fédération se fasse sur le poste client (via JSON-RPC) ou sur le serveur. Lorsque l’on commence à mixer plusieurs services, la réactivité faiblit … ainsi que le niveau de service. Techniquement, le niveau de service d’une application reposant sur plusieurs systèmes est égal à la multiplication des niveaux de service de ces derniers.

Exemple: Une application basée sur 4 APIs d’un niveau de service égal à 99% mensuel possède un niveau de service (sur lequel on peut donc s’engager) de 96%, avec l’hypothèse d’un niveau de service hors APIs tierces égal à 100% …

Idée n° 5: Agrégation de contenus, portails, voire “WebOS” sont le futur du Web

J’adore les services de portails type Netvibes ou iGoogle. Pour moi, cela représente encore ce qu’il y a de meilleur dans le Web2.0. Mais attention à la hype! Certains disent que ces services remplaceront un jour le système d’exploitation … personellement je n’y crois pas trop, en tout cas pas en l’état.

XHTML, Javascript et CSS ne suffisent pas à définir une plate-forme applicative complète, équivalente en fonctionnalités et performance à du client “lourd”. Ok, c’est assez pour faire des widgets (ou gadgets dans Vista) qui sont modérément utiles mais pour des applications complètes, malgré quelques prouesses, il n’y a pas de service au niveau d’un iPhoto ou Picasa en ligne, pour ne citer qu’un exemple. Même l’application Mail de Mac OS X, pourtant faiblarde, reste plus pratique à utiliser que Gmail par exemple.

Dernier problème et celui-là majeur, la sécurité! Les modèles de sécurité des navigateurs Web sont considérés comme insuffisants et sont mis en péril par les nouvelles façon de développer. Par exemple, pour intégrer dynamiquement des services tiers, les développeurs contournent la same origin policy qui empêche de faire des requêtes dynamiques vers d’autres domaines que le site en cours de visite. En gros, cela permet de faire de belles choses mais cela exploite un trou de sécurité et rend l’application vulnérable à des attaques de type XSS ou CSRF (exemple avec Gmail). L’intégration de widgets ou de flux tiers dans Netvibes ou iGoogle rendent ces derniers encore plus vulnérables. D’accord, tout ceci reste confiné aux bornes du navigateur (quoique) mais comme de plus en plus de choses sont gérées dans le navigateur, on n’est pas plus à l’abri.

Le but de cet article n’est pas de “casser” systématiquement toutes les innovations techniques qui suivent la mouvance “2.0″, mais plutôt d’apporter un oeil critique sur la maturité de ces technologies et de remettre en questions des concepts considérés comme évidents. J’utilise d’ailleurs toutes ces techniques dans mes projets personnels (niveau “hobby”). Je pense cependant que le Web2 commence a atteindre les limites de l’architecture web dans son ensemble et qu’il faudra opérer un véritable saut technologique (on sent quelques prémisses comme AIR) pour continuer à satisfaire les besoins actuels et futurs.