An article published on the JetBrains Blog explores the possibility of using Compose HTML to build server-rendered web interfaces in a Kotlin environment, at a time when multiple frameworks are shifting some UI processing to the server. The proposed idea is to provide reusable, type-safe Compose components instead of writing text templates separate from application code. The article emphasizes that what it presents is an exploration of ideas, not an official commitment from JetBrains or an announcement of APIs or a roadmap.
The proposal begins with a comparison to approaches that have emerged in other ecosystems: React introduced server components, HTMX renewed interest in the hypermedia model, while Phoenix LiveView demonstrated the ability to push interactive updates from the server without relying on a client framework. The article argues that the JVM ecosystem has many server-side rendering libraries, but they often rely on template languages and do not offer components sufficiently close to the component concept familiar to JavaScript developers.
Why Compose HTML?
Compose Multiplatform provides a way to write business logic and user interfaces once and share them across Android, iOS, desktop, and the web. However, the current web target in Compose Multiplatform relies on rendering directly inside a canvas, which, according to the article, entails costs related to search engine optimization, loading times, and accessibility.
Compose HTML, which predates Compose for Web, uses Compose Runtime to build single-page applications in Kotlin and then translates them into JavaScript through the Kotlin/JS compiler. The article proposes adding a JVM target to it so that it can perform server-side rendering, allowing an HTML tree to be created directly in Kotlin using real components and types, without a separate template language.
The source presents a side-by-side example of a card component written in Thymeleaf and a Compose component. In the template-based model, the card is defined in a separate file and parameters are passed as strings without type checking. In Compose, the card is a typed function that receives a title of type String and a number of type Int. Therefore, changing the parameter name updates its usage locations through the development environment or produces a compilation error, while passing an incorrect type results in a compiler error instead of a runtime surprise.
A Vision for Server-Side Rendering
The proposed vision requires adding functions such as renderToString and renderToBytes to run the composition process once on the JVM and then convert the resulting tree into HTML text or byte data. According to the example, the process creates components such as text and container elements, waits for the initial composition to stabilize, then traverses the resulting tree and converts it into HTML without a browser or DOM.
This model has clear limitations. It would likely be limited to a single rendering phase, without recomposition when state changes or the execution of effects, making it similar to the concept of server-side rendering in JavaScript frameworks. Event listeners could also be accepted in components, but they would be inactive on the server, since there is no benefit to attaching browser events while HTML is being generated there.
The article presents a vision for a complete task application using Spring Boot, in which a GET route renders the task page, while POST requests add a new task or change its state. In this scenario, interactions would rely on sending actual HTTP forms and reloading the page, without JavaScript on the client side, similar to traditional applications rendered with Thymeleaf, but with the entire interface written inside Compose.
The Current Landscape and Potential Frameworks
Compose HTML currently has only a JS target and therefore does not provide server-side rendering. Nevertheless, the article points to an active ecosystem around Compose for the web. The Kobweb framework is built on Compose HTML and supports static site export and pre-rendering to help improve search engine visibility, but it does not provide SSR. Kilua, meanwhile, relies directly on Compose Runtime to implement SSR and CSR and provides integrations with Ktor, Spring Boot, and others, while Summon provides support for SSR and hydration.
The proposal suggests that adding SSR capabilities to Compose HTML could give Kobweb, Kilua, and Summon a shared foundation instead of relying on three separate paths. It could also give Spring Boot and Ktor frameworks a practical reason to integrate with Compose HTML on the server. However, this outcome is neither guaranteed nor announced; the article describes it as a potential direction that requires experimentation and the definition of the necessary integration points.
Beyond the Initial Rendering
The exploration later moves to the question of hydration and state synchronization: how do components rendered on the server continue their interactive operation in the browser? Do the server and client need to agree on the state? The article indicates that solving these issues could enable UI code to be shared between both sides, so that the same component is compiled for the browser and the server and supports fully integrated web applications written entirely in Kotlin.
However, the vision does not propose turning Compose HTML into a complete, ready-to-use framework containing all components and operations. The closer goal, as the source explains, is to keep the core small and leave the construction of framework integrations and ecosystem libraries to the community, in a manner similar to React, but within a multiplatform library. This differs from other parts of Compose Multiplatform that provide official libraries for Material3, state management, and more.
According to the article, discussions are taking place with the developers of Kobweb, Kilua, and Summon to gather their opinions, alongside the Spring team, which expressed interest in experimenting after a JVM target was added to Compose HTML. Therefore, the current value of this proposal lies in defining a potential direction for web development on the JVM, not in providing an available product or a confirmed feature. If the idea develops, the primary challenge will be balancing the simplicity of the core, integration with server frameworks, and the requirements for interactivity and component reuse between the client and server.