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.

Except the platform is JavaScript, and TypeScript is basically Web IDL aware compiler on steroids, no need to use anything that adds even more layers.

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.

Guest languages are always an impedance mismatch with the underlying platform.

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.

> I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain.

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.