We are interested in running our compose multiplat...

# webassembly

[Tjerk Wolterink]

We are interested in running our compose multiplatform in the app soon, even know with compose ui running in the browser.
However a major bottleneck is that our app assumes a multithreaded environment. We use coroutines to dispatch work off the main thread, in our ViewModels.

However WASM / Kotlin-js doesnt seem to support multithreading at all...
Currently our workaround us using a webworker with kotlin-react bindings and building the UI in react.

However, we are now moving away from this approach for web, and building our web app in vue in typescript.
Major reasons:
• We will also have a customer facing web app, it needs to load fast. A 2MB wasm binary is too much
• Jetpack compose for web is canvas based: Less SEO support
• It allows us to build out a web team without needing kotlin engineers
The major disadvantage is not being able to use kotlin on the web.. We still cross compile our api library and use that.. However ideally we want from some of our web app (backoffice, no SEO required, no quick load time required) to run it in pure kotlin, so its pure cross platform.
But it seems the only way todo that is to rearchitect the app in such a way that i can run on a webworker...
Or to rearchitect the viewmodels to be single threaded, and only do "API" calls to a server (thats how web work).

Is my analysis correct or are there more oppertunities? Will I be able to run multithreaded viewmodels on web any time soon? What would you recommend..

[Big Chungus]

It's not kotlin specific. Web in general is single threaded. However you can still have concurrency (and coroutines support this), just not parallelism

[Oliver.O]

Regarding the Kotlin parts:
• Bundle sizes required for casual web usage will probably be an issue currently with Kotlin/Js and Kotlin/Wasm, depending on which libraries you use.
• SEO will be an issue with Compose Web (Canvas), but not with Compose HTML, which directly manipulates the DOM. Note that the latter has a different API for UI components compared to the other targets of Compose Multiplatform.
• Kotlin/Wasm and Compose Web (Canvas) are still at early stages, so you might want to prototype carefully what works well enough for you. (Though you'd want to carefully prototype anything as even legacy frameworks often do not live up to expectations.)
• Kotlin provides easy-and-safe-to-use concurrency even in single-threaded environments such as the browser (ignoring web workers), which should be sufficient for SEO-friendly DOM-based web applications with small bundle sizes.
Other than that:
• What makes you require multithreading instead of just concurrency in the above use case? (To me, that sound like a fat client approach with some heavy computations in the frontend. And that would smell like large bundles.)
• Going with something like Vue or Svelte instead of React seems reasonable in your case (cf. The self-fulfilling prophecy of React and The Market for Lemons - Infrequently Noted), but results in limited code sharing across frontends (such as mobile or desktop) when compared to Compose-based approaches.

[gagarin55]

Use Flutter, it works everywhere

[Thomas Nattestad]

Just chiming in to say that the web is no longer single threaded and does support concurrency through atomics and SharedArrayBuffer. Coroutines may not be efficiently implementable though, but we are working on Wasm Stack Switching which IIUC should enable it.