Sidenote: I love compose desktop, but am sad that ...

# compose-desktop

[rob42]

Sidenote: I love compose desktop, but am sad that it's built on top of Swing (and the JVM, for that matter).

To get a highly polished experience on Windows, so many win32 (via JNA) and Swing workarounds are required that it would be more straightforward to be using Kotlin native and the platform APIs directly.

Am I right in understanding that the JVM dependency is because compose is built upon Skiko?

[jw]

No. Skiko is capable of providing a native Windows version if it needed to.

[jw]

Skia and skiko are much more useful than not. I think it's more that the JVM was a natural platform to use when porting from Android.

[rob42]

Ah interesting. I suppose for code sharing purposes, being able to use the JVM libraries is useful.

[rob42]

The benefit of compose desktop to me isn't really much about sharing UI code. What I like is, having a single language (kotlin) and mental model for building UI

[rob42]

Probably not the common case though

[jw]

You'd be able to share even if it ran natively on windows. Compose for iOS shows that.

[hfhbd]

Well, it depends on the use case, but if want to have really native UI, it’s a common case. Look at Compose iOS, it’s using skia for native. And it should also be easy to port it on macOS (AppKit). But creating a new UI runtime takes takes, so porting the Android implementation was easy.

[hfhbd]

And of course you can use your businesses logic using compose states (or flows using molecule) with the native UI framework, eg SwiftUI.

[rob42]

I imagine it would also result in a < 100MB release binary size too (which would be nice).

Windows is where I think this could really shine, because there's arguably no "native" UI toolkit, and there's also not the carryover of knowledge from mobile that iOS->macOS has.

Native feeling UI on mac that's not actually AppKit is kind of a lost cause, but on Windows it's doable.

[hfhbd]

The native UI is WinUI supporting C++, so you need to create the compose UI runtime using Kotlin native and its C interop and some glue code too, which takes time to have a good experience.

[hfhbd]

I think you should be able to reuse Google Material using skiko/skia directly, but I would not count Google Material as native UI on Windows though.

[rob42]

I'd probably build new UI controls in compose for most things, rather than proxying to WinUI. My argument is that windows has no native controls because almost every application (including Microsoft's own) is using a custom toolkit.

I think win32 + compose would be all you'd need.

[hfhbd]

Another key aspect why JVM first is the ecosystem, the JVM ecosystem is huge, so developers can easily use a 3rd party library, but the Kotlin native ones is very small not covering all business use-cases.

[rob42]

^ That's probably the strongest argument imo.

Though it would still be great to be able to opt out of the JVM and stick with pure kotlin.

[jw]

Yes it would, but it's just lower priority. Hopefully it comes

[Kirill Grouchnikov]

Swing was the most logical choice to give new life to the Jetbrains’s primary line of business - IDEs that also happen to be written in Swing. Not only that, IDEs that happen to run on JB’s own fork of the Java runtime, which is where Jewel seems to be heading as well.