If I want to eventually release my UI in about six...
# compose-web
e
If I want to eventually release my UI in about six months for web only, would it make sense to develop as a desktop app for now since wasm is still experimental, and then convert once wasm is more mature, or would it make sense to use a different framework? I really like the idea of using kotlin for full stack and want to use prebuilt components that compose give me so I spend most of my time just building functionality. Or would it make sense to use the js version of compose which sounds like it might be obsolete in the future?
o
Some thoughts: • Wasm is certainly the future, but you don't really need Wasm immediately, since Compose Web can also be driven via Kotlin/Js (mostly the same API). Then the question would be: Will Compose Web mature fast enough? • Compose Web requires Skiko: Can you live with an initial download size of at least 3 MB? • Would Compose Html be a viable fallback option (different API)?
e
Thanks Oliver. This would be an admin type app so a large download seems ok. I didn't realize Compose web can have JS as a target in addition to wasm. If that's the case then seems like I should just use the JS target until wasm matures especially since its mostly the same API. If Compose Html has a different API then I worry I'll be stuck since sounds like it may become obsolete since wasm is the future.
o
For an admin-type app, would Compose Desktop make a viable fallback option? In that case, I'd go the Compose way. Otherwise I'd say it would be wise to prepare a contingency plan in case Compose Web still has some quirks. For example, with current releases, text fields need to improve (caret vanishing when starting to type). Depending on the complexity of your UI, maybe a prototype would help to clarify.
e
yeah that's what I was initially thinking. A desktop app could be useful by itself since my tool would be used by a business to validate the quality of their data by defining validation rules that get run against their data periodically to find anomalies. If I develop initially as a desktop, then as wasm matures, I could provide the web interface as well. Do you think the API for desktop would match fairly closely with wasm? I know its experimental so its hard to say.
I'll try working up a desktop prototype
o
Regarding the API it is fairly close now, and I don’t expect that to change. Entry points are different, also some platform-specific things, but whatever goes into a single window is basically identical.
d
@Oliver.O it looks like Compose Wasm still uses the Skiko JS library. Aren't there plans to create a Skiko Wasm binary? In such case can we expect it to be less than 3MB?
o
Skiko.js is just the entry point. It’s all Wasm under the hood.
d
Ok, I see
I was hoping there could be some selective/optimized compilation of the Wasm canvas, just including the code that is only needed by your app.
o
I don’t have sufficient knowledge on the details, but maybe the upcoming support for ES6 modules helps to shrink bundle sizes for Compose/Skiko, too.
s
@Oliver.O I didn't know that Compose Web has a JS target. Where can I read about this? I tried using Compose HTML, but with no frontend web experience it's taking ages. If I could just use Android-like APIs, my life would be so much easier. 😅
o
The experimental Web/Js/Canvas target still exists, but seems to be phased out in favor of WebAssembly, which all documentation now refers to. You can still find an example at https://github.com/JetBrains/compose-multiplatform-core/tree/jb-main/compose/mpp/demo. Most people seem to use some variant of my BrowserViewportWindow function as an entry point like so, then it's basically a Compose Jetpack API inside, but not as recent. Note that resizing with
BrowserViewportWindow
no longer works on Kotlin 1.9.0. So until WebAssembly is ready for prime-time, you might just use the experimental Js/Canvas target where it works, or go the easier route with Compose Desktop in the mean time.
s
@Oliver.O Amazing, thanks!