Is the wasm target supported by Compose HTML? Than...
# compose-web
n
Is the wasm target supported by Compose HTML? Thanks.
s
I wasn't able to use Compose HTML in my wasmJsMain
1
😢 1
🙏 1
r
Wasm is not supported by Compose HTML. I'm working on an alternative approach: https://github.com/rjaros/kilua/
👍 4
😮 2
s
s
@soufianehamama9 That’s not what he asked for.
s
@Stefan Oltmann Oh 😮 thanks
a
Still wondering why someone would need to draw HTML layouts, using Wasm code, for their UI logic. May you share your usecase??
s
I guess it’s a combination of wanting the performance of WASM and still needing Compose HMTL while Compose for Web is not ready.
a
Does that mean one would switch to Compose for Web when C4W is stable??? and ditch C4H?
r
I think (correct me if I'm wrong here) with Compose for Web (canvas based) you can only build android-like apps using material components. You can't just build a website or web application using your favorite CSS framework, can't use one of thousands commercial or free bootstrap/bulma/tailwind/etc. templates. You don't have normal accessibility. Last but not least you can't use html/css.Javascript components (or web-components) from NPM ecosystem.
A goal is to have all this + wasm performance.
a
My assumption. We are talking about a UI thats written declaratively. so then, this "wasm performance", is it expected to be achieved by letting wasm create DOM nodes using javascript interop?? also, web components (as per my knowledge), are written in javascript, do we still expect some performance gains by rendering web components from a function invoked in wasm??
Also, Correcting you on the wrong parts above. Compose 4 Web can be used to build different apps even ones that don't resemble android at all. Its just that, most people are currently sharing their code with android, thats why it seems androidy but that is definitely not its limitation. More over, you don't have to rely on material components. Problem is, currently material is the only design system that has a feature rich set of Composables, but material itself is implemented ontop of Compose (not within it). There other community driven design systems (i.e. aurora) one can use, or you might even create your own (as you can and potentially would with Compose HTML)
I think apart from the strength and weaknesses of sharing UI with other targets, Compose 4 Web is suitable for graphics heavy applications (i.e. Figma, Games), things like spreadsheets, Image Editors, e.t.c
r
You could be asking why C4W is targeting wasm when it could just target js. It's also just a "declarative UI". In my opinion the performance gain is independent whether you use canvas or html. You can already see performance benefits of wasm over js in my kilua project.
👍🏻 1
👍 1
👍🏾 1
n
Compose for Web and Compose HTML are two different technologies although they are both based on the core Compose libraries. It is a big mistake that these two technologies are discussed in the same Slack channel. We tried to reason to make a separate channel for Compose for Web and rename this channel to compose-html without success - now it is a mixture of both, causing lot of confusion. Back to the topic, web applications in general (and parts of Compose HTML as well) may benefit from switching to wasm e.g. by achieving smaller "binary" size and faster performance. At least we hope that the footprint of Kotlin/WASM web applications will be smaller and their performance will be better than the current Kotlin/JS applications. And I'm talking about "traditional" HTML-based PWAs using Compose HTML, not Compose for Web applications.
Compose 4 Web can be used to build different apps even ones that don't resemble android at all.
It is far from trivial to write a custom "widget set" that is well designed, performant, feature-rich, etc. - and actively maintained!
> I'm working on an alternative approach: https://github.com/rjaros/kilua/ Wow, it seems amazing! Considering the very low priority of Compose HTML at Jetbrains, it is nice to see an alternative.