Un artículo publicado en el blog de JetBrains explora la posibilidad de utilizar Compose HTML para crear interfaces web renderizadas desde el servidor en un entorno Kotlin, en un momento en que varios marcos están trasladando parte del procesamiento de las interfaces al servidor. La idea propuesta consiste en proporcionar componentes Compose reutilizables y con seguridad de tipos, en lugar de escribir plantillas de texto separadas del código de la aplicación. El artículo recalca que lo planteado representa una exploración de ideas y no un compromiso oficial de JetBrains ni un anuncio de API o de una hoja de ruta.
La propuesta parte de una comparación con vías surgidas en otros ecosistemas: React lanzó los componentes de servidor y HTMX renovó el interés por el modelo hypermedia, mientras que Phoenix LiveView demostró que es posible enviar actualizaciones interactivas desde el servidor sin depender de un marco de cliente. El artículo considera que el ecosistema JVM dispone de numerosas bibliotecas para el renderizado desde el servidor, pero que suelen depender de lenguajes de plantillas y no ofrecen componentes suficientemente cercanos al concepto de componentes que conocen los desarrolladores de JavaScript.
¿Por qué Compose HTML?
Compose Multiplatform ofrece una forma de escribir la lógica de negocio y las interfaces de usuario una sola vez y compartirlas entre Android, iOS, equipos de escritorio y la web. Sin embargo, el objetivo web actual de Compose Multiplatform depende de renderizar directamente en un canvas, lo que, según el artículo, implica costes relacionados con la optimización para motores de búsqueda, los tiempos de carga y la accesibilidad.
Compose HTML, anterior a Compose for Web, utiliza Compose Runtime para crear aplicaciones de una sola página en Kotlin y después traducirlas a JavaScript mediante el compilador Kotlin/JS. El artículo propone añadirle un objetivo JVM para que pueda ejecutar el renderizado desde el servidor, de modo que el árbol HTML se cree directamente en Kotlin utilizando componentes y tipos reales, sin un lenguaje de plantillas separado.
La fuente muestra un ejemplo comparativo entre un componente de tarjeta escrito en Thymeleaf y un componente Compose. En el modelo basado en plantillas, la tarjeta se define en un archivo independiente y los parámetros se pasan como cadenas no vinculadas a una comprobación de tipos. En Compose, en cambio, la tarjeta es una función typed que recibe un título de tipo String y un número de tipo Int. Por ello, cambiar el nombre del parámetro actualiza los lugares donde se utiliza mediante el entorno de desarrollo o produce un error durante la compilación; asimismo, pasar un tipo incorrecto provoca un error del compilador en lugar de una sorpresa durante la ejecución.
Concepto del renderizado desde el servidor
El concepto propuesto requiere añadir funciones como renderToString y renderToBytes para ejecutar el proceso de composición una sola vez en la JVM y después convertir el árbol resultante en texto HTML o datos binarios. Según el ejemplo incluido, el proceso crea componentes como texto y elementos contenedores, espera a que la composición inicial se estabilice, recorre el árbol resultante y lo convierte en HTML sin navegador ni DOM.
Este modelo tiene limitaciones claras. Es probable que se limite a una única fase de renderizado, sin recomposición cuando cambie el estado ni ejecución de efectos, lo que lo acercaría al concepto de renderizado desde el servidor presente en los marcos de JavaScript. También se pueden aceptar escuchas de eventos en los componentes, pero permanecerán inactivas en el servidor, ya que no tiene sentido vincular eventos del navegador mientras se crea HTML allí.
El artículo presenta el concepto de una aplicación de tareas completa utilizando Spring Boot: una ruta GET mostraría la página de tareas, mientras que las solicitudes POST añadirían una tarea nueva o cambiarían su estado. En este escenario, las interacciones dependerían del envío de formularios HTTP reales y de la recarga de la página, sin JavaScript en el lado del cliente, de forma similar a las aplicaciones de renderizado tradicionales con Thymeleaf, pero escribiendo toda la interfaz dentro de Compose.
Situación actual y posibles marcos
Actualmente Compose HTML solo tiene un objetivo JS, por lo que no proporciona renderizado desde el servidor. No obstante, el artículo señala que existe un ecosistema activo en torno a Compose para la web. El marco Kobweb está construido sobre Compose HTML y admite la exportación de sitios estáticos y el prerenderizado para ayudar a mejorar la visibilidad en los motores de búsqueda, pero no ofrece SSR. Kilua, por su parte, depende directamente de Compose Runtime para ejecutar SSR y CSR, y ofrece integraciones con Ktor, Spring Boot y otros, mientras que Summon proporciona compatibilidad con SSR e hydration.
La propuesta considera que añadir capacidades de SSR a Compose HTML podría proporcionar a Kobweb, Kilua y Summon una base común en lugar de tres vías independientes. También podría dar a los marcos Spring Boot y Ktor una razón práctica para integrarse con Compose HTML en el servidor. Sin embargo, este resultado no está garantizado ni anunciado; el artículo lo describe como una posible dirección que requiere experimentación y la determinación de los puntos de integración necesarios.
Más allá del renderizado inicial
La exploración pasa después a la cuestión de la hydration y la sincronización del estado: ¿cómo continúan su funcionamiento interactivo en el navegador los componentes renderizados en el servidor? ¿Y necesitan el servidor y el cliente ponerse de acuerdo sobre el estado? El artículo señala que resolver estas cuestiones podría permitir compartir el código de la interfaz entre ambas partes, de modo que el mismo componente se traduzca para el navegador y para el servidor, y admita aplicaciones web interactivas completas escritas enteramente en Kotlin.
Sin embargo, el concepto no propone convertir Compose HTML en un marco integral listo para usar que incluya todos los componentes y operaciones. El objetivo más cercano, como explica la fuente, es mantener el núcleo pequeño y dejar la creación de integraciones con marcos y bibliotecas del ecosistema a la comunidad, siguiendo un enfoque similar al de React, pero dentro de una biblioteca multiplataforma. Esto difiere de otras partes de Compose Multiplatform, que proporcionan bibliotecas oficiales para Material3, la gestión del estado y otros aspectos.
Según el artículo, se están manteniendo conversaciones con los desarrolladores de Kobweb, Kilua y Summon para recopilar sus opiniones, además del equipo de Spring, que mostró interés en experimentar después de añadir un objetivo JVM a Compose HTML. Por tanto, el valor actual de esta propuesta reside en definir una posible dirección para el desarrollo web en la JVM, no en ofrecer un producto disponible o una función confirmada. Si la idea evoluciona, el desafío principal será equilibrar la sencillez del núcleo, la integración con los marcos de servidor y los requisitos de interactividad y reutilización de componentes entre el cliente y el servidor.