compose-multiplatform VS kotlinx.coroutines

JetBrains has a simplified example of a general-purpose Compose text viewer here: https://github.com/JetBrains/compose-multiplatform/blob/master/examples/codeviewer/shared/src/commonMain/kotlin/org/jetbrains/codeviewer/ui/editor/Editor.kt

Say 20000 lines of text. It won't work in Compose Desktop according to an official response. There is no alternative nor solution, until someone else in the community reinvents the wheel.

Kamel is an asynchronous media loading library for Compose Multiplatform.

Kotlin Compose Multiplatform is the way to do Desktop apps. https://github.com/JetBrains/compose-multiplatform

As for missing controls, a common one is a grid. They have built in grids, but again they are built for Android and don't make any sense in a desktop app. There is no simple way to create an Excel-like Data Grid like you might see in Windows Forms, although it can be done. https://github.com/JetBrains/compose-multiplatform/issues/344.

Compose for Web is now called "Compose HTML Library", with the Kotlin/Wasm target now called Compose for Web instead

And of course there are lots of resources linked in the https://github.com/JetBrains/compose-multiplatform repo too.

In the next few months, I'm expecting to see a Kotlin canvas release in alpha or something for Compose Web Canvas for Compose Multiplatform - https://github.com/JetBrains/compose-multiplatform

Also, what about existing components, according to docs, there are not too many? https://github.com/JetBrains/compose-multiplatform/blob/master/README.md

Kotlin has coroutines that are supported by the language and implemented by a library (the implementation remains platform-dependent): kotlinx.coroutines and a sandbox environment is available here to try it out.

Sure! runCatching catches Throwable right? Well when you cancel a coroutine it throws a CancellationException and this gets used as a signal to stop execution. runCatching stops that signal so the coroutine keeps running. Lemme find you a link real quick https://github.com/Kotlin/kotlinx.coroutines/issues/1814

According to the author of kotlinx.coroutines lib, it will try to keep the same thread if possible but not always. After my question, he updated the document of Dispatchers.IO to be like this https://github.com/Kotlin/kotlinx.coroutines/pull/3236/files This dispatcher and its views share threads with the [Default][Dispatchers.Default] dispatcher, so using `withContext(Dispatchers.IO) { ... }` when already running on the [Default][Dispatchers.Default] dispatcher typically does not lead to an actual switching to another thread. In such scenarios, the underlying implementation attempts to keep the execution on the same thread on a best-effort basis.

I think it is a great question and you can ask it on github

This is the issue I posted in GitHub https://github.com/Kotlin/kotlinx.coroutines/issues/3234 Thank you for the suggestion

DI: Dependency injection: Check out Dagger Hilt, Koin or Kodine. Architecture: Android tends to be MVVM but, MVP, MVI and some others exist. Async calls: For kotlin, coroutines. Rxjava can be used with kotlin or java. I'm not actually sure how java devs do asyn calls these days.

Kotlin based, Coroutines + Flow for asynchronous.

Interestingly, Kotlin Coroutines have been available and in production for a LONG time now.

https://github.com/Kotlin/kotlinx.coroutines

In fact, Kotlin Coroutines are an brilliant on the android platform. We are talking severely memory and CPU constrained architectures here.

That said, Kotlin Coroutines are popularly used in production on server side - https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/

So here's the thing - I would doubt anyone would switch to Java Virtual Threads anytime soon.

Anyways, it seems like it's a common enough issue that it is getting the attention of the kotlin team. I have high hopes for this PR that looks like it might be close to merging, and has activity within the last couple of days.