De JSF à AngularJS

Ce matin j’ai partagé sur Twitter cet article en anglais qui fait une comparaison entre AngularJS et JSF. D’autres que moi l’ont partagé aussi, mais il y a eu quelques réactions étonnées, du genre : “c’est une blague ?”.

Pour moi la comparaison n’a rien d’absurde, et mérite de plus amples explications que ce qu’on peut écrire dans un tweet de 140 caractères.

Tout comme l’auteur de l’article, je viens du monde Java et j’ai travaillé avec JSF pendant 5 ans, certes surtout comme architecte et en support à mes collègues qui l’utilisaient au quotidien, mais j’ai aussi fait ma part de développements. Et moi aussi en découvrant AngularJS, j’ai forcément constaté des ressemblances entre les deux frameworks.

Des templates déclaratifs avec data-binding...

Tout d’abord, quand je parle de JSF, ce n’était pas le JSF des origines avec des templates en JSP et des tonnes de fichiers de configuration en XML, une horreur que je n’aurais jamais accepté d’utiliser. Il s’agissait d’une combinaison de JSF, de Facelets pour les templates (qui est la technologie de templates utilisée dans JSF 2.0), et du framework Seam (devenu Weld) pour l’injection de dépendances des services, et leur publication dans les différents contextes afin qu’ils soient directement utilisables pour le data-binding des composants JSF. N’allez pas raconter que j’ai dit qu’AngularJS ressemblait aux immondes pages JSP, je démentirai formellement !

Avec cette combinaison JSF + Facelets + Seam (ou Spring si vous voulez), on a des templates déclaratifs basés sur HTML avec du data-binding et un langage d'expression, qui ressemblent beaucoup à ceux d’AngularJS comme l'a très bien montré l'auteur de l'article cité. Je suis un grand partisan des templates déclaratifs. Je trouve l’approche déclarative beaucoup plus efficace que l’approche procédurale pour la création d’une interface utilisateur. Avant JSF, j’ai fait plusieurs années de Swing, et j’avais pu constater à quel point c’était lourd ; puissant certes, mais avec une lourdeur toujours présente pour une puissance rarement nécessaire. Quand on doit écrire un éditeur “rich text”, on apprécie la puissance de Swing, mais pour des usages plus classiques on passe son temps à maudire sa lourdeur. JavaFX était une très bonne idée, celle de rajouter des templates déclaratifs à la puissance de Swing, dommage qu’elle soit arrivée trop tard.

Mais revenons-en à nos templates JSF/Facelets. Aussi similaires soient-ils, il y a quand même des différences avec ceux d’AngularJS. Déjà, les composants JSF sont forcéments des éléments du pseudo XHTML, alors que les directives d’AngularJS peuvent être aussi des attributs. Du coup avec AngularJS, on peut avoir plusieurs directives sur un même élément : une directive est généralement un comportement applicable à un élément plutôt que l’élément lui-même. Avec Facelets, il faut imbriquer plusieurs composants JSF pour combiner leurs comportements.

... mais traités côté serveur

Une différence bien plus fondamentale, c’est que le template AngularJS est du HTML qui est analysé par le navigateur web avant qu’AngularJS n’intervienne dessus, tandis qu’avec JSF, c’est le moteur de Facelets qui convertit côté serveur le template en HTML pur. Avantage pour JSF, comme le traitement est fait côté serveur, on a un accès direct aux objets Java du serveur, notamment aux entités persistantes. Il n’y a pas besoin d’une couche intermédiaire de web services pour échanger les données avec le client, c’est nettement plus simple, surtout lorsqu’il y a une gestion assez pointue des droits sur les données de ces objets. Par contre AngularJS est plus proche du HTML, travaille en manipulant le DOM dans le navigateur web plutôt qu’en générant du HTML souvent trop verbeux comme le font les composants JSF. On aura d’une façon générale avec AngularJS des pages HTML plus propres et moins lourdes.

L’autre gros problème de JSF, c’est le stockage de l’état des composants, qui peut se faire côté serveur ou côté client. Encore qu’il est difficile d’envisager sérieusement le stockage de l’état côté serveur : comme JSF ne sait pas vraiment ce qu’il se passe dans le navigateur, il faut conserver l’état de plein de pages pour espérer qu’un utilisateur ayant ouvert plusieurs onglets ne soumette pas un formulaire d’une page dont l’état a été perdu ; inutile de préciser que dans ce mode la consommation de mémoire par utilisateur connecté est tout simplement colossale. Le mode qui fonctionne mieux, c’est celui consistant à stocker l’état des composants JSF sérialisé dans un champ caché de la page web. Plus de problème de consommation de mémoire côté serveur, ni de pages dont l’état a été perdu puisqu’il est conservé dans la page elle-même, mais ça implique de gros échanges pour passer dans un sens et dans l’autre cet état sérialisé, pour la moindre requête Ajax. Alors on en vient à faire un peu de jQuery pour éviter ces lourds échanges serveurs dès qu’on veut mettre un peu d’interaction dans une page web. Le résultat, c'est qu'on mélange du code client dans le template serveur, et ce qui était plutôt élégant devient horrible à maintenir.

Du web “terminal passif” au web “client-serveur”

C’est là qu’on touche aux limites du fait de gérer côté serveur une interface client. JSF, du moins une combinaison JSF + Facelets + Seam, est très efficace pour créer des applications web classiques, pour ne pas dire à l’ancienne, avec des pages web distinctes et peu d’Ajax. C’est le web façon terminal passif. Pour ce genre d’applications, gérer l’interface utilisateur côté client, même avec un framework aussi pratique qu’AngularJS, suppose de créer toute une API en web services REST échangeant du JSON, ce dont on est dispensé avec JSF.

Mais dès qu’on veut faire une application web plus réactive, éventuellement mono-page, c’est-à-dire quand on veut passer du web terminal passif au web client-serveur, alors JSF n’est plus du tout pertinent, et AngularJS s’avère un bien meilleur choix. JavaScript est de nos jours largement assez puissant pour gérer dans le navigateur web toute la couche de présentation d’une application, et c’est une approche beaucoup plus logique et plus cohérence, pour avoir de l’interaction sans échange avec le serveur, pour gérer correctement l’historique du navigateur dans une application mono-page.. En bref, on peut maintenant abandonner les solutions trop complexes et d’un autre âge, qui découlaient de la nécessité de gérer la présentation dans une technologie complètement déconnectée du langage natif du navigateur web, et même souvent exécutée côté serveur. Pour moi les JSF, GWT ou autre Vaadin apparaissent aujourd'hui comme des impasses de l’évolution du développement web, des espèces condamnées à l’extinction à plus ou moins court terme.

Et si un client JavaScript suppose une API en web services pour l’échange des données, c’est de toute façon une architecture qui se généralise car elle permet aussi de communiquer avec des applications mobiles, ou des services externes. Donc oui, on peut encore trouver des cas où une application web pourra être développée plus rapidement avec JSF qu’avec AngularJS, si ce n’est pas une application mono-page, qu’elle comporte peu d’interactions côté client, qu’il n’y aura pas de version mobile, etc. Ça n’empêche pas que malgré leurs similitudes, l’approche de JSF est du passé, et c’est celle d’AngularJS qui prévaudra pour ces prochaines années. Les ressemblances permettront une transition plus facile pour les anciens de JSF, et c'est une bonne chose.