Hey everyone :wave: I've written a small blog pos...
# compose-web
f
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
kodee excited 5
👍 1
h
How is this different to kotlinx-html?
k
Mostly: reuse existing compose code from clients
h
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.
But you cannot use launch or sideeffect
And how can you reuse code if you want to target html? The html api is completely different to the Canvas api
k
for SSR + SEO
f
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
kodee intensifies 2
h
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.
Also, the compose html code already has the JVM target, but the JVM target has no Kotlin source code.
f
sure but still something that'll need work
s
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