Are you looking into isomorphic rendering? One of ...

# compose-web

[jw]

Are you looking into isomorphic rendering? One of the things I couldn't get working (with my own Compose DOM implementation) was to render an initial tree on the server and resume it on the client without re-emitting the initial DOM tree. Maybe that initial re-render isn't terrible, but it'd be nice to skip it.

[olonho]

Not yet, currently no SSR in Compose for Web is being done by our team

[shikasd]

I was briefly looking into this some time ago
I had two ideas on the matter:
1) create dom on server and instead of recreating it, try to use it when emitting nodes on client. It works similar to react hydration and has the same drawbacks of duplicating the data and initial diffing, but it helps static content to render faster. I was experimenting with JVM server, that worked, but didn't go far.
2) In case both server and client are on JS and we can guarantee same ids for groups in composition, one could try serialize that instead, so initial diffing is not required. The problem here is deserializing composition, I didn't really figure it out yet.

[jw]

Yeah I'm on JVM server. I basically had a giant boolean in my Applier where I traversed the existing DOM instead of creating/building. And the ComposeNode factory had an indirection for lookup up existing nodes vs. creating new ones as well. It... kinda worked, but we're not using Compose at this layer so I kinda abandoned it.

[shikasd]

Yep, same thing
Probably a good approximation if someone wants to host a landing page written in Compose, but it is still forces recreation initial composition from scratch

[louiscad]

Is there any issue to subscribe to about SSR in Compose for Web?

[MrPowerGamerBR]

+1, if SSR was available with Compose Web it would be a excellent choice for almost anything!

Currently my "let's rewrite in Compose!" ideas are limited to stuff that doesn't need to care about SEO (after all, non-SSR pages are not indexed by non-Google search engines and even Google struggles to index JS only pages sometimes), but sadly most of the stuff that I could rewrite with Compose are big projects that would take too long to be rewritten.

[pabl0rg]

@olonho easy SSR would be huge. Ecommerce sites need it for good SEO.

Someone else commented as much on reddit:

https://www.reddit.com/r/Kotlin/comments/nekhx6/jetpack_compose_for_web_putting_order_to_chaos/gyi2v5f/?utm_source=share&utm_medium=ios_app

[louiscad]

@pabl0rg You can already roll your own in Kotlin, after the renderComposable(…) { … } call:

console.log(document.documentElement!!.outerHTML)

or right in the browser console with plain JS:

console.log(document.documentElement.outerHTML);

These calls log the current DOM, which is a snapshot of your rendered app.

[pabl0rg]

So, when running server-side (JVM) we can call renderComposable? Then client-side it will re-render everything?

[louiscad]

No, but you can use that document.documentElement!!.outerHTML locally or in CI to generate a static webpage that you can store, deploy to a CDN like Firebase hosting or whatever, and I think you can also get that to run in a nodejs server.

[Arkady Bazhanov]

SSR is not just static pages. Actually, I believe, static pages cover very little of what SSR is needed for

[louiscad]

Sure. However, you can still hack around to have contentless static pages that are then rendered with updated data.