Blog

Avenir des applications web RIA

Thierry Chatel • 11 juin 2012

Entre l'adoption progressive de HTML5 et l'apparition de frameworks clients JavaScript chaque jour plus nombreux, c'est l'occasion de faire un panorama des différentes alternatives pour réaliser des applications RIA ("Rich Internet Applications").

Il est possible de faire une application RIA avec un framework serveur supportant Ajax, comme JSF, ou en utilisant du jQuery dans des pages PHP ou autres. C'est une option qui reste pertinente, et n'est pas près de disparaître, mais nous allons nous limiter aux outils permettant de réaliser un vrai client séparé s'exécutant entièrement dans le navigateur web.

Flex

Le framework Flex d'Adobe a connu un succès relatif. Il s'exécute soit dans le navigateur web via le plugin Flash, soit sur la machine virtuelle AIR (Adobe Integrated Runtime) ce qui permet d'avoir de vraies applications de type "desktop", s'exécutant hors du navigateur.

Flex fournit tous les composants nécessaires à la création de l'interface utilisateur d'une application, et aux échanges de données avec le serveur, généralement sous la forme de services web. C'est une plate-forme qui s'est beaucoup enrichie au cours de ces dernières années, et qui est bien mieux adaptée que le HTML à l'écriture d'applications.

Mais l'avenir de Flex est plutôt sombre. Adobe a abandonné le support du plugin Flash dans les navigateurs mobiles (smartphones et tablettes), ce qui restreint l'usage de Flex sur ces périphériques aux applications AIR. Adobe a aussi décidé de donner le framework Flex à la fondation Apache, mais est-ce pour en faire un projet open source plus ouvert ou pour s'en désengager progressivement ? On peut se poser la question. La tendance, y compris chez Adobe, est d'aller vers du HTML5, et aussi bien Flex que Flash sont vraisemblablement amenés à disparaître à court ou moyen terme.

Donc malgré ses qualités bien réelles, la tendance est plutôt à l'abandon de Flex.

GWT

Le framework GWT de Google permet de développer en Java l'interface utilisateur d'une application web, comme on le ferait avec Swing. Le client web ainsi développé est automatiquement transcrit en JavaScript, et s'exécute dans le navigateur sans aucun plugin, tout le contenu est construit par le framework à partir des éléments normaux du DOM HTML.

Disons-le franchement, GWT c'est une grosse bidouille, certes une superbe bidouille qui fonctionne bien, mais une bidouille quand même. GWT offre une abstraction complète de la plate-forme HTML et JavaScript, le développeur a l'impression de réaliser une interface utilisateur de type desktop en Java, alors qu'au final dans le navigateur tout a été converti en JavaScript et HTML. C'est un peu une prouesse technologique, car l'abstraction fonctionne vraiment bien, et le code JavaScript généré est bien optimisé.

GWT a connu et connaît encore un succès mérité, même si cette approche est loin d'être la panacée. Le fait de développer le client en Java présente des avantages mais pose aussi des problèmes, car les objets Java manipulés dans le code du client seront en fait convertis en JavaScript dans le navigateur web. Alors certes, on peut utiliser dans la partie cliente les classes métiers du serveur, mais il ne s'agira pas des mêmes objets, il faudra gérer la communication entre les deux, les échanges d'objets, leur synchronisation. Il est totalement illusoire d'espérer utiliser facilement des entités persistantes gérées par Hibernate ou les EJB 3.0 côté client, car elles seront forcément déconnectées du serveur, et le lazy loading ne pourra pas marcher.

L'avenir de GWT n'est probablement pas aussi sombre que celui de Flex, mais c'est un framework qui n'est plus forcément dans l'air du temps. Il n'y a pas d'engagement clair de la part de Google quant au futur de GWT. Google investit aussi dans d'autres technologies, comme le langage Dart lui aussi compilé en JavaScript. GWT est utilisé par Google comme framework pour le développement de certains projets importants, comme l'interface d'administration Adwords, ou Chrome Web Store, ou encore les nouvelles versions des Googles Groups et de Blogger. C'est loin d'être marginal, même si pour le mastodonte qu'est Google ce n'est pas non plus un engagement massif.

Le problème c'est plutôt que GWT semble de moins en moins nécessaire. A une époque où créer une interface sophistiquée en HTML et JavaScript relevait de la gageure à cause de problèmes de compatibilité entre les navigateurs, des bizarreries du langage JavaScript et de l'absence de framework JavaScript bien conçu, GWT pouvait apparaître comme une solution salvatrice. Aujourd'hui c'est beaucoup moins vrai, les navigateurs récents respectent beaucoup mieux les standards, et avec les bons outils on peut faire aussi bien et plus simplement qu'avec GWT. Même si l'on verra sans aucun doute des applications GWT pendant encore quelques années, à mon avis GWT, au moins sous sa forme actuelle, fait déjà plus partie de l'histoire du développement web que de son avenir.

Frameworks JavaScript

Il suffit de voir le buzz actuel autour des frameworks JavaScript pour penser que la tendance actuelle du développement d'applications RIA se trouve là. Mais le buzz ne suffit pas, et de nombreux projets qui par le passé ont suscité une grande effervescence sont finalement restés relativement marginaux.

Cette fois il ne s'agit pas seulement de buzz, la tendance est bien réelle car elle répond à un besoin avéré. L'architecture web classique avec des pages générées côté serveur atteint ses limites. Créer ainsi une interface utilisateur réactive et moderne n'a rien d'élégant, à cause du mélange entre le code serveur et le code client, qui est lourd à maintenir et à faire évoluer, et difficilement testable. Cette architecture classique ne permet pas de supporter un mode déconnecté, elle ne favorise pas l'interopérabilité avec d'autres types de clients comme des applications mobiles natives, et augmente la charge du serveur par rapport à un vrai client s'exécutant dans le navigateur.

Après de nombreuses années d'applications web façon terminal passif (un peu plus évolué quand même), les outils sont là pour faire du vrai client-serveur dans le navigateur, et c'est à mon avis la tendance qui va s'affirmer sur les prochaines années. De plus en plus les applications RIA seront construites avec un framework JavaScript permettant de réaliser un client complet, bien structuré, et autonome car le contenu des pages web ne sera pas généré côté serveur. Un tel client se connecte à un serveur fournissant simplement des données, avec une API de type REST, toute la couche de présentation de l'application étant déportée dans le navigateur web.

Ces frameworks existent déjà, et une application comme Trello est bâtie de cette façon. Le plus connu de ces frameworks est Backbone.js, qui a récemment fait l'objet d'une BackboneConf à Boston - où étaient aussi présentés quelques outils concurrents.

To bind or not to bind

Si ces nombreux frameworks présentent des caractéristiques ou des approches variées, il y a un aspect suffisamment différenciateur pour qu'on puisse les classer en deux catégories : ceux qui font du "data binding", et ceux qui n'en font pas. Backbone.js ou Spine, par exemple, ne proposent pas de data binding, alors que pour Ember.js, Knockout ou AngularJS, le data binding est au cœur du framework. Le data binding, c'est la possibilité de lier de façon permanente un élément de la vue (la page web) à une propriété d'un objet JavaScript dans le modèle de données.

Dans les frameworks faisant de la génération à partir de templates, on va aussi faire le lien entre des éléments de la vue et les données correspondantes du modèle, mais c'est un lien instantané qui n'existe que pour la génération du HTML. Avec du data binding, surtout s'il est bidirectionnel, le lien est permanent, et toute modification d'une donnée dans un champ de la vue entraînera la mise à jour de la propriété correspondante dans le modèle, et réciproquement toute modification de la valeur d'une propriété dans le modèle entraînera son rafraîchissement automatique dans la vue.

Avec le framework AngularJS et son moteur de data binding bidirectionnel, les vues ne contiennent aucun code, seulement les déclarations des bindings, et c'est le framework qui gère seul le rafraîchissement des vues. Les contrôleurs écrits par les développeurs travaillent uniquement sur le modèle de données, et ne contiennent aucun code destiné à rafraîchir l'affichage. C'est encore mieux que ça, car les contrôleurs ne contiennent aucune référence aux vues chargées de l'affichage, ce qui permet de les tester de façon unitaire sans aucune vue, fût-elle simulée.

Il y a déjà longtemps, j'ai travaillé plusieurs années sur une application avec un client Java Swing, bâti avec un framework maison fonctionnant par data binding et rafraîchissement automatique. Le fait de n'écrire que le code correspondant à la logique de présentation sans avoir à se préoccuper du rafraîchissement des vues est un gain énorme, à la fois sur la taille du code et sur la facilité de test unitaire. AngularJS est à ce point de vue ce que j'ai vu de plus simple à tester en terme de framework d'interface utilisateur, toutes technologies confondues, que ce soit pour des applications web ou de type desktop. Si la couche de présentation d'une application est souvent celle qu'on néglige de tester parce l'imbrication du code avec le système des vues rend l'écriture de tests unitaires pénible et coûteuse, l'isolation totale du code des contrôleurs dans une application AngularJS rend le code de présentation aussi facile à tester que des services métiers.

Le data binding n'est pas simplement une fonction supplémentaire, il permet de réduire de façon drastique le travail du développeur, au point que je ne vois aucun intérêt à utiliser des frameworks comme Backbone.js, très bas niveau et sans data binding, alors qu'apparaissent maintenant des plates-formes de haut niveau simplifiant largement l'écriture d'applications web. Inutile de vous dire lequel de ces frameworks a ma préférence, vous l'aurez deviné.

Frameworks full-stack de développement rapide

Une autre option émerge ces temps-ci, avec des frameworks complets pour réaliser à la fois la partie cliente et la partie serveur d'une application web, souvent les deux en JavaScript en s'appuyant sur un serveur Node.js. On peut citer par exemple Meteor, ou Derby.

Ces plates-formes de développement rapide peuvent être très intéressantes pour du prototypage, pour obtenir très vite un résultat fonctionnel. Dans le long terme, je suis beaucoup plus hésitant, car un logiciel développé ainsi sera complètement dépendant d'une plate-forme très particulière, qui n'est pas nécessairement la plus judicieuse. On se retrouve avec un logiciel totalement lié à du Node.js, du MongoDB ou autre, qui peuvent être de très bons outils quand ils sont appropriés, mais qui ne sont pas plus que les autres des solutions universelles.

J'ai tendance à préférer une architecture plus découplée, avec la possibilité de choisir les outils les plus appropriés pour les différentes couches, et avec l'option d'en changer ultérieurement si ça s'avère nécessaire. Il est possible d'arriver à un bon compromis entre rapidité de développement et souplesse de la plate-forme, quitte à s'écrire quelques outils pour simplifier les tâches récurrentes, sans s'enfermer dans une plate-forme figée trop contraignante, qui ne pourra jamais convenir à tous les besoins.

Derniers billets

11 juin 2012

Avenir des applications web RIA

Ou la percée des frameworks clients JavaScript dans le développement d'applications web.

5 avril 2012

Exemples d'utilisation du framework AngularJS

Voici les fichiers des exemples que j'ai montrés lors de ma présentation du framework AngularJS à Montpellier.

15 mars 2012

AngularJS, énième framework JavaScript ou pierre angulaire des applications web ?

Un nouveau framework qui révolutionne l'écriture de clients web, et destiné à connaître un gros succès.

6 septembre 2011

Informatisation des processus et facteur humain

Ou quels sont les inconvénients du déterminisme induit par l'informatisation, et comment les éviter au maximum ?

26 août 2011

Ergonomie des applications web et productivité

Quelles fonctionnalités plus ou moins courantes sur internet peuvent être adoptées avec succès dans des applications de gestion, pour permettre un travail plus efficace ?

11 août 2011

Réutilisation et recyclage

Que peut-on apprendre de la navette spatiale américaine à propos de la réutilisation de code en informatique ?

Flux

Atom