Hey everyone :wave: I've written a small blog pos...

# compose-web

[Frederik Pietzko]

Hey everyone 👋

I've written a small blog post about the possibility to use compose-html on the server to build fullstack web applications using Kotlin and how integrations into Spring and Ktor might look and feel like!
Quick Disclaimer: at this point in time this is just something we are exploring together with the community and does not represent an official commitment.
But we would nevertheless like to hear your feedback on the topic! Feel free to join the #C0BM8FWG58Q Slack channel and share your feedback!

blog.jetbrains.com/kotlin/2026/08/exploring-compose-html-for-server-side-rendering

[hfhbd]

How is this different to kotlinx-html?

[Konstantin Tskhovrebov]

Mostly: reuse existing compose code from clients

[hfhbd]

How? You send the generated html and you cannot update the html from the server after it is been sent (without using websockets etc.)
The power of compose vs a normal builder is the option to update the tree over time.

[hfhbd]

But you cannot use launch or sideeffect

[hfhbd]

And how can you reuse code if you want to target html? The html api is completely different to the Canvas api

[Konstantin Tskhovrebov]

for SSR + SEO

[Frederik Pietzko]

Atm not that different from kotlinx-html, although I'd argue that compose-dsl & components are nicer to use than extension function. With the added benefit that we could build it up at some point support hydration. On client you could then update the tree over time. But first things first -> add jvm target to compose-html & kotlin-browser

[hfhbd]

Well, kind of. With compose code, you can write code that will never be executed after sending the html to the client, (any updates to the state), but a normal dsl will prevent that, because you can't use composable code in the first time.

[hfhbd]

Also, the compose html code already has the JVM target, but the JVM target has no Kotlin source code.

[Frederik Pietzko]

sure but still something that'll need work

[Seri]

I like this approach, and have been researching a way to do something similar to build my own portfolio site! I want to have some shared interface/language between the Compose mobile code that I write and the website I'll publish, but I'm not fond of Compose Multiplatform for simple blog-style sites

[Arjan van Wieringen]

This is confusing. During KotlinConf they explicitly said that Compose HTML will not be developed further except for supporting libraries like KobWeb, Kilua etc.

But now it appears not to be so 🤣

[Frederik Pietzko]

@Arjan van Wieringen At the moment this is still just in the experimentation and idea phase. So no hard commitments made yet. We are starting by making compose-html and a few other libraries work on the JVM and Sebastian Deleuze from the Spring Team has commited to start experimenting with it afterwards and build a spring-poc on their end.

We decided to communicate early in order to enable discussions and identify if users are interested in this.

[Christopher Mederos]

maybe interesting to see ktor + htmx + compose-html as a stack choice for interactivity

[Konstantin Tskhovrebov]

The idea is to reuse an already existing code base

[bod]

Sorry my feedback is not precisely on that blog post (which I find very interesting!) but I just want to say I wish compose-html (font-end) had more of a focus and priority. I find it to be an excellent technology but it looks like it doesn't get much love from JetBrains, at least in terms of visibility/awareness.

[jessewilson]

compose-html is EXCELLENT technology that embraces the web idiomatically and natively.

I use it, I love it, and I want to see it flourish. So I'm very excited about this idea!