JetBrains says the JVM missed server rendering. Its proposed fix is Compose, not templates.

JetBrains has published a post on the Kotlin blog arguing that every ecosystem is rediscovering the server as a place to render UI except the JVM, and floating Compose HTML with a JVM target as Kotlin's way in ^[1][2][3]. The post states outright that it is an exploration rather than an official commitment ^[4], which is the sentence to keep in view before this turns into a framework decision in someone's backlog.

The framing is competitive. React shipped Server Components, HTMX made hypermedia interesting again, and Phoenix LiveView showed a server pushing interactive UI updates with no client framework in sight ^[5]. Next, Nuxt and SvelteKit give React, Vue and Svelte an SSR story, and C#, Rust and Elixir have their own approaches that bundle state and rendering into reusable components in code ^[6]. The complaint about the JVM is not that SSR libraries are missing; it is that most of them need a templating language and have nothing close enough to a component for a JS developer to recognise as one ^[7].

The proposed mechanism is narrower than the pitch. Compose HTML already exists, predates Compose for Web, and uses the Compose runtime to build SPAs compiled to JS by the Kotlin/JS compiler ^[8]. Today it has a JS target only, so there is no SSR path ^[9], and the exploration amounts to adding a JVM target so rendering happens in Kotlin with real components and no templating language ^[10]. Compose Multiplatform's existing web support is not a substitute: it renders into a canvas, sharing UI code with mobile at the cost of SEO, loading times, and accessibility ^[11].

The concrete argument is a rename. In the Thymeleaf example, a card fragment lives in its own file, is called by name, and takes parameters passed as untyped strings; rename `count` to `itemCount` and every call site keeps compiling until it breaks at runtime, because the compiler has no idea the fragment or its parameters exist ^[12]. The Compose version is a typed `@Composable` function taking `title: String` and `count: Int`; a rename either propagates through the IDE or fails to compile, and passing a `String` where an `Int` is expected is a compiler error rather than a runtime surprise ^[13]. That is the whole proposition: moving template defects from request time to build time. Kotlin's Java interoperability is the second half, since it would let the approach slot into large legacy Java applications ^[14].

It is worth noting what already ships. Kobweb is a batteries-included framework built on Compose HTML that supports static site export and prerendering to help with SEO, but does not offer SSR ^[15]. Kilua skips Compose HTML and builds on the Compose runtime directly, doing both SSR and CSR on JS or Wasm ^[16]. So server rendering from the Compose runtime exists in Kotlin today; what does not exist is that capability on Compose HTML from a JVM target ^[17].

What to watch is whether a JVM target for Compose HTML shows up as committed work rather than prose, and what happens to interactivity. The published material argues rendering and type safety; it does not describe how a server would push interactive updates the way it credits Phoenix LiveView with doing ^[18]. Teams currently on Thymeleaf or JSP, or reaching for a separate JS framework to go fullstack ^[19], can treat this as a direction of travel. Teams that need server rendering in Kotlin this quarter are looking at Kilua, not at this.