I'm kind of surprised <#C01D6HTPATV|compose-desktop> has more interest / traffic (non-scientifically...

# compose-web

[rocketraman]

I'm kind of surprised #compose-desktop has more interest / traffic (non-scientifically judging by number of people in the channel, frequency of posts and number of reactions) than #compose-web does. Is #compose-desktop simply solving a more immediate gap in the JVM world, whereas #compose-web has many existing alternatives people are mostly happy with? Or maybe #compose-web just got a later start.

[christophsturm]

i think the reason is that people think that compose-desktop is more production ready and compose web is more of a prototype. thats what i think, but i may be wrong

[spierce7]

compose-web is newer, and compose-desktop also has a much better UI sharing story with compose’s primary user base - android

It’s very easy for me to create a Compose Android / Desktop application, but to include web in that currently is significantly more challenging.

I will start using web more regularly when web canvas rendering is released.

[Big Chungus]

Also web has shitloads of modern frameworks to choose from, while desktop has only flutter as declarative alternative

[Big Chungus]

Aditionally, web has no material support (I'm slowly working on it)

[Michael Paus]

Maybe everybody is just waiting for #compose-web-canvas 😉 But of course that is just pure speculation and wishful thinking.

[Nikola Milovic]

@Michael Paus the canvas support would allow UI sharing between the other platforms and the web right? Tbh I was hoping they would go that route instead of DOM's

[Michael Paus]

@Nikola Milovic I understand that both concepts make sense and have their specific use cases. My personal preference is the #compose-web-canvas variant though.

[Tomasz Krakowiak]

I am waiting for server-side rendering ; p

[Michael Paus]

@Tomasz Krakowiak Yes, that’s maybe the third reasonable alternative. Something like https://www.jpro.one/ for JavaFX.

[Tomasz Krakowiak]

@Michael Paus I don't think it supports it. I guess it works more like Vaadin. SSR - https://www.omnisci.com/technical-glossary/server-side-rendering

[rocketraman]

Yeah the point of SSR is that content is served to the browser quickly -- with traditional client side frameworks all of the Javascript has to download and load first, then API calls have to be made, and then only does the page show useful info. The client-side framework can load asynchronously in the background.

All the modern JS frameworks these days are making SSR work because its been shown to have a huge positive impact on FCP and LCP metrics.

[rocketraman]

Rendering to canvas vs HTML is a totally orthogonal issue.

[Tomasz Krakowiak]

It also has significant impact on SEO and how quickly changes to content are indexed by search engines.

[rocketraman]

That's right. Though that's less of a concern these days now that crawler bots have basic JS support.

[Tomasz Krakowiak]

It still impacts SEO rank and how frequent pages are indexed by some search engines(eg. google). I think they use different crawlers for sites that does not require JS and for one that does.

[rocketraman]

A term commonly used is "isomorphic" -- a page that renders the same on server-side and client-side. However some of the best JS frameworks have moved beyond isomorphic and are filling in as much as they can on the server-side and then hydrating the rest client side for maximum perf. And some have different modes depending on whether you are optimizing for FCP/LCP or SEO.

[Dragos Rachieru]

I always created CLI apps for desktop because creating GUI apps was too hard for me, until compose-jb, I have tried tornadoFX before, but it was still pretty hard to use, I gave up on my project after some time. But with compose-jb I created a fully working project for both Android and Desktop with shared code between backend and frontend, I'm just waiting for canvas support for web to port my app to Web as well.