Un article publié sur le blog de JetBrains explore la possibilité d’utiliser Compose HTML pour construire des interfaces web rendues côté serveur dans un environnement Kotlin, à un moment où plusieurs frameworks réorientent une partie du traitement des interfaces vers le serveur. L’idée proposée consiste à fournir des composants Compose réutilisables et bénéficiant d’une sécurité de typage, plutôt qu’à écrire des modèles textuels séparés du code de l’application. L’article insiste sur le fait que cette proposition constitue une exploration d’idées, et non un engagement officiel de JetBrains ni une annonce d’API ou de feuille de route.
La proposition part d’une comparaison avec des approches apparues dans d’autres écosystèmes : React a lancé les composants serveur, HTMX a ravivé l’intérêt pour le modèle hypermedia, tandis que Phoenix LiveView a démontré qu’il était possible d’envoyer des mises à jour interactives depuis le serveur sans dépendre d’un framework client. L’article estime que l’écosystème JVM dispose de nombreuses bibliothèques de rendu côté serveur, mais qu’elles reposent souvent sur des langages de modèles et ne proposent pas de composants suffisamment proches du concept de composant connu des développeurs JavaScript.
Pourquoi Compose HTML ?
Compose Multiplatform offre une manière d’écrire une seule fois la logique métier et les interfaces utilisateur, puis de les partager entre Android, iOS, les ordinateurs de bureau et le web. Toutefois, la cible web actuelle de Compose Multiplatform repose sur un rendu direct dans un canvas, ce qui entraîne, selon l’article, des coûts liés à l’optimisation pour les moteurs de recherche, aux temps de chargement et à l’accessibilité.
Compose HTML, antérieur à Compose for Web, utilise Compose Runtime pour créer des applications monopage en Kotlin, puis les traduire en JavaScript au moyen du compilateur Kotlin/JS. L’article propose de lui ajouter une cible JVM afin de permettre le rendu côté serveur : un arbre HTML serait ainsi créé directement en Kotlin à l’aide de composants et de types réels, sans langage de modèles distinct.
La source présente un exemple comparatif entre un composant de carte écrit en Thymeleaf et un composant Compose. Dans le modèle fondé sur des modèles, la carte est définie dans un fichier distinct et les paramètres sont transmis sous forme de chaînes non soumises à une vérification de type. Avec Compose, en revanche, la carte est une fonction typée qui reçoit un titre de type String et un nombre de type Int. Ainsi, modifier le nom du paramètre entraîne la mise à jour des emplacements d’utilisation via l’environnement de développement ou une erreur lors de la compilation ; de même, transmettre un type incorrect provoque une erreur du compilateur plutôt qu’une surprise à l’exécution.
Vision du rendu côté serveur
La vision proposée nécessiterait l’ajout de fonctions telles que renderToString et renderToBytes pour exécuter une seule fois la composition sur la JVM, puis convertir l’arbre obtenu en texte HTML ou en données binaires. Selon l’exemple fourni, le processus crée des composants tels que du texte et des éléments conteneurs, attend la stabilisation de la composition initiale, puis parcourt l’arbre obtenu et le convertit en HTML sans navigateur ni DOM.
Ce modèle comporte des limites évidentes. Il serait probablement limité à une seule phase de rendu, sans recomposition lors d’un changement d’état ni exécution d’effets, ce qui le rapprocherait du concept de rendu côté serveur des frameworks JavaScript. Les composants pourraient également accepter des écouteurs d’événements, mais ceux-ci resteraient inactifs sur le serveur, puisqu’il n’est pas utile d’associer des événements du navigateur pendant la création du HTML côté serveur.
L’article présente la vision d’une application complète de gestion de tâches utilisant Spring Boot : une route GET afficherait la page des tâches, tandis que des requêtes POST ajouteraient une nouvelle tâche ou modifieraient son état. Dans ce scénario, les interactions reposeraient sur l’envoi de véritables formulaires HTTP et le rechargement de la page, sans JavaScript côté client, à l’instar des applications de rendu traditionnelles utilisant Thymeleaf, mais avec une interface entièrement écrite en Compose.
Paysage actuel et frameworks potentiels
Compose HTML ne dispose actuellement que d’une cible JS et ne fournit donc pas de rendu côté serveur. L’article signale toutefois l’existence d’un écosystème actif autour de Compose pour le web. Le framework Kobweb repose sur Compose HTML et prend en charge l’exportation de sites statiques ainsi que le pré-rendu pour contribuer à l’optimisation pour les moteurs de recherche, mais il ne fournit pas de SSR. Kilua s’appuie directement sur Compose Runtime pour exécuter le SSR et le CSR, et propose des intégrations avec Ktor, Spring Boot et d’autres outils, tandis que Summon prend en charge le SSR et l’hydratation.
La proposition estime que l’ajout de capacités SSR à Compose HTML pourrait fournir à Kobweb, Kilua et Summon une base commune, au lieu de trois voies distinctes. Elle pourrait également donner aux frameworks Spring Boot et Ktor une raison concrète de s’intégrer à Compose HTML côté serveur. Cependant, ce résultat n’est ni garanti ni annoncé ; l’article le décrit comme une direction potentielle nécessitant des expérimentations et la définition des points d’intégration requis.
Au-delà du rendu initial
L’exploration aborde ensuite la question de l’hydratation et de la synchronisation de l’état : comment des composants rendus sur le serveur poursuivent-ils leur fonctionnement interactif dans le navigateur ? Le serveur et le client doivent-ils se mettre d’accord sur l’état ? L’article indique que la résolution de ces questions pourrait permettre de partager le code de l’interface entre les deux parties : le même composant serait compilé pour le navigateur et pour le serveur, afin de prendre en charge des applications web interactives complètes écrites entièrement en Kotlin.
La vision ne propose toutefois pas de transformer Compose HTML en un framework complet prêt à l’emploi comprenant tous les composants et toutes les fonctionnalités. L’objectif le plus proche, comme l’explique la source, consiste à conserver un noyau réduit et à laisser la construction des intégrations de frameworks et des bibliothèques de l’écosystème à la communauté, selon une approche similaire à celle de React, mais au sein d’une bibliothèque multiplateforme. Cela diffère d’autres parties de Compose Multiplatform, qui fournissent des bibliothèques officielles pour Material3, la gestion de l’état et d’autres éléments.
Selon l’article, des discussions sont en cours avec les développeurs de Kobweb, Kilua et Summon afin de recueillir leurs avis, ainsi qu’avec l’équipe Spring, qui a manifesté son intérêt pour l’expérimentation après l’ajout d’une cible JVM à Compose HTML. La valeur actuelle de cette proposition réside donc dans la définition d’une direction potentielle pour le développement web sur la JVM, et non dans la fourniture d’un produit disponible ou d’une fonctionnalité confirmée. Si l’idée évolue, le principal défi consistera à trouver un équilibre entre la simplicité du noyau, l’intégration avec les frameworks serveur et les exigences d’interactivité et de réutilisation des composants entre le client et le serveur.