Historique des composants côté serveur, des templates aux composants modernes

Historique: des composants côté serveur, des templates aux composants modernes

Des JSP aux frameworks front-end modernes, la manière de construire des interfaces web a beaucoup évolué. Pourtant, une question reste la même : comment produire du HTML dynamique, réutilisable et facile à maintenir ? Les premiers templates Java : générer du HTML depuis le serveur

Les premiers templates Java : générer du HTML depuis le serveur

Au début du web dynamique en Java, les servlets permettaient de répondre aux requêtes et de générer des pages. Fabriquer une page HTML en concaténant des chaînes Java devenait vite pénible : le code applicatif et le balisage se retrouvaient entremêlés.

Les JSP (JavaServer Pages, arrivé en 1999) ont popularisé une approche inverse : écrire du HTML dans lequel on insère des éléments dynamiques. Elles ont rendu la création de pages plus naturelle pour les développeurs front-end, mais l’usage de code Java directement dans le template pouvait vite brouiller la séparation entre présentation et logique applicative. Les bibliothèques de balises, puis l’EL et la JSTL, ont aidé à réduire cette imbrication.

D’autres moteurs ont mis l’accent sur la séparation entre le template et les données. FreeMarker, apparu à la fin des années 1990, propose son propre langage de templates, le FTL, avec des directives, des macros et des mécanismes de réutilisation. L’application fournit un modèle de données ; le template s’en sert pour produire le résultat. FreeMarker a ainsi trouvé sa place pour générer du HTML, mais aussi des courriels, des documents et d’autres contenus textuels.

Velocity, lancé au début des années 2000 par le projet Apache Jakarta, poursuivait une idée comparable : laisser le template présenter les données fournies par l’application, plutôt que d’y écrire la logique métier. Sa syntaxe concise et son modèle de macros ont contribué à populariser les moteurs de templates indépendants du framework applicatif.

Ces outils ont rendu le rendu serveur plus lisible et plus modulaire. Mais, dans leur forme classique, un template ou une macro reste souvent un mécanisme de réutilisation : le contrat entre l’appelant et le morceau de template: ses entrées, leur type et les emplacements de contenu personnalisables n’est pas toujours explicite ni vérifié par le compilateur.

Tapestry et Wicket : le serveur adopte les composants

Une autre branche de l’histoire a placé les composants d’interface au centre du développement Java. Tapestry (2000) et Wicket (2004) ont proposé de construire les pages en assemblant des éléments plus autonomes, plutôt que de considérer les templates comme de simples fichiers contenant des substitutions.

Un composant peut représenter une partie identifiable de l’interface et s’inscrire dans une structure plus large. Wicket, par exemple, organise les interfaces autour d’une hiérarchie de composants Java associée à du balisage. Tapestry fournit des pages et des composants gérés par le framework, avec des mécanismes de cycle de vie et de traitement des événements.

Ces frameworks ont apporté au serveur des idées qui sont aujourd’hui courantes côté navigateur : encapsulation, composition et réutilisation. En contrepartie, l’interface est plus étroitement liée au framework et à ses mécanismes. Cette architecture est pertinente pour des interfaces riches, mais peut sembler imposante lorsqu’on veut simplement partager un panneau ou une carte HTML.

Spring MVC (2003) et Struts (2000) sont basé sur des actions, alors que Tapestry et Wicket sont basé état comme des application de bureau comme on en développe avec Swing / JavaFX.

La dernière version de wicket date d'octobre 2026.     

GWT : écrire l’interface en Java, l’exécuter dans le navigateur

Google Web Toolkit (GWT) est arrivé en 2006 et a proposé une autre voie pour créer des interfaces web riches : écrire le code client en Java, puis le compiler en JavaScript exécuté dans le navigateur. GWT fournissait aussi des widgets et des outils pour structurer l’interface, ainsi qu’un mécanisme de communication avec le serveur.

GWT n’est donc pas un moteur de templates serveur comme JSP, FreeMarker ou Thymeleaf. Il marque plutôt une étape vers les applications web où une part importante de l’interface et de son comportement s’exécute côté navigateur. Il a permis à des équipes Java de développer ce type d’application sans écrire directement tout leur code en JavaScript, mais introduisait en contrepartie une compilation spécifique et une séparation plus nette entre code client et code serveur.

SenchaGWT et smartgwt ont su apporter une couche de composant très avancé (même encore aujourd’hui ) au dessus de GWT.     

Angular, React et Vue : les composants passent dans le navigateur

Avec Angular (2010), React (2013) et Vue (2014) , le composant est devenu un élément central des applications front-end. Un composant reçoit des données:  inputs ou props et peut être assemblé avec d’autres. Il peut aussi accueillir du contenu fourni par son parent, par exemple via des slots ou des mécanismes de projection de contenu.

Cette approche structure les interfaces et facilite les interactions riches. Mais toute cette puissance a un coût qui dépend du projet : chaîne de compilation JavaScript, état côté client, routage, appels réseau, gestion des formulaires, rendu initial, hydratation ou synchronisation entre le serveur et le navigateur.

On se retrouve souvent actuellement avec une autre couche côté serveur, le BFF afin que le navigateur n'est pas le token.

Ces frameworks/librairies ont déplacé une partie de la complexité du serveur vers le navigateur, transformant le développement web de manière radicale: state management, routing, rendering). Ils permettent même de générer les pages sur le serveur.

Ce niveau de complexité peut être justifié dans certaines d’applications. Il ne l’est pas nécessairement pour toutes les pages. Si une interface sert surtout à afficher des données, le serveur peut générer le HTML directement, sans imposer au navigateur un framework complet.

Thymeleaf : des fragments utiles, mais différents des composants

Dans l’écosystème Java, Thymeleaf sortie en 2011, offre une approche HTML-first, avec des fragments qui peuvent être réutilisés et recevoir des paramètres. C’est utile pour partager une navigation, un pied de page ou un morceau de formulaire.

Un fragment reste toutefois, en général, une portion de template. Il ne définit pas forcément une frontière de composant aussi explicite qu’une API : quelles données sont attendues ? Quels emplacements de contenu le parent peut-il remplir ? Ces attentes sont-elles vérifiées avant l’exécution ?

Thymeleaf est le moteur de template serveur le plus utilisé en Java, même s'il y en a plusieurs autres tel que jte, thim, rocker. Même si thymeleaf n'est pas le plus performance, c'est lui qui offre le plus de fonctionnalités.

SPA, Single Page Application

Même si le concept existait avant eux via XMLHttpRequest ou ajax, c'est avec l'arrivé des librairies/framework frontend, que le rafraîchissement partiel de la page connait un véritable succès.

Une panoplie delibrairie tel quehtmx utilisable avec votre moteur de template serveur préféré permet d'éviter le rafraîchissement de la page au complet.