Hey all, I wrote a post about various issues to co...

# kobweb

[David Herman]

Hey all, I wrote a post about various issues to consider when deciding to write your project in Compose HTML vs Compose Multiplatform for Web.

https://bitspittle.dev/blog/2024/c4w

Feel free to share any thoughts or feedback in the thread! 🧵

[David Herman]

I suspect if people are already in this channel, they may already be on the same page about what the post is saying anyway! But a peer suggested I write it after I kept answering the same questions over and over to users who were asking about Compose HTML vs CMP for Web.

[David Herman]

If people identify any mistakes or think that something is missing and/or worded poorly, I'm open for all feedback.

[Ryan Scott]

Will do 🙂

[Ahmed Riyadh]

> I'm open for all feedback.
This might be I'm open to all feedback instead

A minor change:

> In contrast, when I checked a Flutter web app, it required a 2MB download for its rendering engine and an additional few hundred KB for the site itself.
Flutter has two web renderers (HTML or Canvas)

The support for Flutter WASM has been stable in Flutter 3.21.

It hasn't been used by most projects yet, I heard Flutter WASM is smaller when using it instead of Flutter Web JS instead though I haven't tried it out yet.

So you might consider updating the text to be a bit more specific.

[David Herman]

Sure, I'll see if I can find the project again. I'm pretty sure it was WASM.

[rocketraman]

I believe JetBrains should be more transparent about the tradeoffs and limitations of each approach, rather than only promoting C4W as a one-size-fits-all solution.

This 💯

[David Herman]

Honestly I wish I didn't have to write the article! That was a few days I could have been coding instead... But I'm worried that devs might get wowed by the tantalizing promise of C4W, get burned by it, and then ditch the ecosystem without realizing there were other options.

[Filip Wiesner]

I think JetBrains just wants to push the cross-platform story because that's appealing to managers; it's not about the devs. The promise of "write once, use everywhere" is just too good to pass up for a lot of people even though it delivers a subpar experience.

[rocketraman]

I'm not sure that's true. JetBrains has traditionally been extremely developer-focused, with the attitude of: get the devs, and management will follow. Plus, as a dev that tends to work on small teams for small shops, C4W is just as tantalizing to me as it is to management.

[David Herman]

We'd only be conjecturing without knowing what is going on behind the scenes. I'll be honest, my fears align with what @Filip Wiesner is saying, but my heart hopes that @rocketraman is correct. JetBrains in the past has absolutely been dev-first, but they're also a business, and businesses like to simplify products and messaging, which can sometimes be at odds with a dev-first approach.

At the very least, the team has been continuing to push out updated versions of Compose HTML every time a new Compose version comes out, so I'm grateful for that.

[Hans van Dodewaard]

Compose HTML is the production-ready web-based Compose solution available at the moment​ I think. We are currently building a web application with it that will soon go online.​ it's a nice framework to develop with.

It would be ​n​ice if JetBrains expressed a clear commitment to Compose HTML in the future. During the last kotlinconf, it was hardly discussed as far as I know.

At present, it still feels ​a bit risky to start developing ​new long running projects with it.

[David Herman]

@Hans van Dodewaard yes, 💯.

I'm hoping that we'll get more and more people in the community making great websites with Compose HTML so that it will be a no-brainer for JetBrains to make more public commitments to supporting it.

I think already we have stuff that they could have proudly showed off at the last Kotlinconf, but as you said, no luck. Ah well, I'll keep applying to get a talk about Kobweb in there 🤞.

[CLOVIS]

I do think JB is being dev-first here: the story of reusing your Android code as-is is very compelling. I'm not convinced the drawbacks for end users make the canvas approach worth it, but I do think JB has good intentions.