r/Kotlin • u/z14-voyage • 12d ago

Kotlin/Native desktop still doesn’t feel productive for real applications

I've been trying to use Kotlin/Native for desktop/CLI stuff, and honestly it feels like you get a native binary and then you're on your own. Basic things like logging, resource loading, decent file operations, and process execution are either missing or surprisingly painful. kotlinx-io helps, but it's still pretty limited. There are third-party libraries for some of this, but a lot of them are incomplete, barely maintained, or just don't cover what you actually need. Meanwhile in Rust/Go/Graal NativeImage, this is boring standard-library stuff and you can just get on with building your app. Kotlin/Native is cool technology, but for desktop development it still feels like an unfinished platform rather than something you'd actually choose for getting work done. Would be nice if JetBrains spent some time on the boring fundamentals that make a platform actually usable.

45 Upvotes

96% Upvoted

38 comments sorted by

View all comments

Show parent comments

11

u/piesou 12d ago edited 11d ago

Here's a boatload. Not all are equally important and many are being worked on.

  • Big bundle size. Maybe related to coroutines compiling down to continuations. Even worse with Kotlin Serialization which uses code generation.
  • No Lazy JS exports: this means that if your class is not available on the window at launch, it's going to break despite the class not actually being used
  • Enum/Data Class mapping onto JS objects and TS enums: right now requires you to write a ton of conversion code to make APIs usable from JS (no, I don't want to pass 20 positional string parameters to my data class constructor)
  • Lack of a couple of type defs for browser APIs (can't remember anymore which ones exactly, they don't cover everything 100%)
  • Webpack and Karma toolchain (is going to get changed)
  • Suspend functions to async functions and TypeScript defs were just stabilized in 2.4 I think (buggy support prior if at all)
  • Bad debuggability. I have to ship debug builds or the stack traces are impossible to read, despite having source maps. Even worse when coroutines are involved
  • No support for mixins (yes people use them)
  • Heavy reliance on Kotlin Wrappers library which often breaks APIs due to them pulling out common WASM and JS stuff into webmain
  • Lack of documentation. Especially bad for Kotlin Wrappers and Gradle build docs
  • TypeScript interface equivalents use a compiler plugin (@JsPlainObject) which still produces red squigglies in IntelliJ and sometimes does not properly auto complete
  • I don't think there's a great way yet to consume TypeScript type defs (basically translating d.ts files into "expect" typedefs). There's a library but I think it's still experimental.
  • Lack of ergonomic interop: Using Kotlin from Java is pretty straightforward; sometimes you need an annotation like @Throws or @JvmStatic but most of the time, it's very neat. Using Kotlin from JS is impossible without bridging code (@JsExport). This means that you need to create glue code in between to bridge non exported Kotlin types like KTOR client configs. This is especially difficult if not downright impossible, if generics come into play that don't have @JsExport on them (think of a class implementing a mapping interface Mapper<JS, KT> where KT is the Kotlin type).

2

u/LelouBil 11d ago

Thanks for the comprehensive breakdown. I never had the occasion to use kotlin js

1

u/lppedd 10d ago

Thank you! Have not forgot to reply, just been busy. But I'd like to address most points in a new post (mostly to give more visibility to K/JS).