Kotlin/Native is hardly a stable target, given that they botched the implementation by going with an incompatible memory model as Java, and have spent the last year fixing it by rebooting it with a proper GC implementation.
Hardly any better than just using GraalVM or any other JVM AOT compiler, some of which go back to early 2000's even if only available in commercial JDKs.
The JavaScript compilation target still needs to do some catching up with TypeScript.
I feel the non-JVM targets are a real distraction from what is a lovely language. I’d rather they focussed more on fixing the issues with kotlin in IntelliJ - you’d think controlling both the language and the IDE would result in a less buggy experience than the current situation.
My personal open source evening hacking project for the last year or two has been a Kotlin multiplatform project. It's language interpreter that runs on the JVM, Native and Javascript.
Since the project is an interpreter, it's easy to do performance testing between the different platforms. I just write some program in my language, and run it on each implementation.
The results are interesting. The JVM target is consistently 20 times faster than native. Now some of this is because memory allocations are so fast in the JVM, so if your programs does less memory allocations the difference won't be that great. However, if you compile Kotlin to native code, one has to accept that it's much slower.
Another problem with native compilation is that it's quite slow. I wouldn't want to do all my development using native, but rather develop using the JVM and then compile to native for the use cases that need it.
The only time I think that native would make sense is if you absolutely cannot run the JVM for some reason. One such reason would be for embedded (which would have to be ARM, since that's the only embedded architecture that's supported).
It's actually very good - debugging from the IDE now even works. I'd recommend building around KVision rather than raw KotlinJs (https://kvision.gitbook.io/kvision-guide/).
The main thing that can be annoying is figuring out module exports from a js library that you want to use (which is probably easy enough if you have a modern javascript background). I haven't found a library that's stumped me yet, but some are more annoying than others. Jetbrains have a tool called Dukat which will supposedly one day automate this, but for now it's not there.
Distribution size can be an issue, but it's not terrible. My current (moderately complex) app is floating at around 2MB. I haven't tried splitting it up, though that is possible.
That depends. If the rest of your application is in Kotlin, you're reducing cognitive overhead. Same language, same compile, same distribution. You can share view models between frontend and backend. It's much closer to what GWT promised to be than GWT ever was.
I absolutely love Kotlin for backend web dev, I started using it as "Java but without the things in Java that piss me off" but the more I used its non-Java features the more I grew to love it. Sadly I've moved jobs so I'm not using it professionally any more but it powers my side project so I'm keeping my skills fresh.
I'd recommend it to anyone where they'd traditionally use Java or another similar language.
Hardly any better than just using GraalVM or any other JVM AOT compiler, some of which go back to early 2000's even if only available in commercial JDKs.
The JavaScript compilation target still needs to do some catching up with TypeScript.