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.
It gets stuck indexing forever, losing all code completion and navigation abilities until it’s restarted.
Git integration sometimes stops working. It will list the files to be committed but does nothing when you click commit, until it’s restarted.
Exiting presentation mode leaves the font set to a huge size (until it’s restarted).
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).
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.
I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain.
I did vote against stuff like GWT already several times, and every time it has been proven to have been the right decision, when things went hot.
Fair enough, that's a different argument from the one you posed upthread though. The ecosystem and tooling are very much there.
Happy to disagree on architectural merit of the approach. Personally I'm done with javascript/typescript for any future products/teams I build, and am glad to have a viable solution.