I have only played a little with the Kotlin web stuff, but no I would not recommend doing anything serious with it.

I think JS/TS are king because of the ecosystem and wealth of documentation. My experience with more "niche" front-end languages is that you have to do much more yourself or have lots of messy interactions with plain JS libraries.

But even if Kotlin JS had an enormous ecosystem, I'm not sure I would love it. What I love about Kotlin is that it is a great replacement for Java. Interoperating with java has zero performance overhead and zero mental overhead. Because of this and Kotlin's general closeness to Java, many more places writing JVM code are comfortable with using Kotlin compared with other JVM languages like Scala or Clojure. Kotlin cleans up the Java syntax and adds nice features like type inferencing, non-null by default, coroutines, blocks, extension functions and so on.

But if we're not on the JVM, I'm definitely not sold on Kotlin as the perfect language or anything. Sealed classes are nice, but still not as nice as tagged unions. As far as type systems go, I think the one in TS is more flexible and expressive.

Like Kotlin, what I like about TS is the zero mental overhead integration with JS and the JS ecosystem. But if we're not tied to a browser, I guess I wouldn't ever really want to program in TS.

Node is kind of remarkable in that it is the backend platform that is most similar to a browser, which makes these full-stack setups a little more natural. Not sure I'm sold on their value in general since most teams are going to be big enough that front-end and backend code are written separately. If you want to keep types in sync, I think graphql or protocol buffers are better solutions.

It's early days. 1.3.70 was only released a few weeks ago and featured a major overhaul of the kotlin-js related tooling.

I gave it a quick try a few weeks ago and it's actually nice. Before that, it wasn't really usable (dead code elimination was a problem, webpack integration kind of sucked, etc.). With the new tools, it's stupidly easy. It uses webpack and karma underneath but it's all driven from gradle and it works without any webpack or karma specific configuration (you can customize of course). You can depend on both npms and kotlin-js jars. There's a gradle plugin under development that translates typescript declarations for npms to kotlin. So, the development experience is pretty nice. But it will take a while for this to mature and get more users. IMHO the upcoming 1.4 release might kick off some adoption.

IMHO what it needs is proper kotlin frameworks for frontend. Yes, you can use vue and react, etc. But they are kind of optimized for people used to untyped blobs of json. Slapping the word state on this does not quite get you to a level that would be comfortable to a Kotlin developer that also develops for Android. IMHO, it's just a matter of time before people discover 1) you can now do frontend with Kotlin and it doesn't suck 2) we should just scrap the few hundred kb of code that actually gets imported at runtime (i.e. react and related cruft) and build that up from the ground and 4) there's a ton of stuff that was already done for Android that ports over relatively well to the browser world. That's actually a lot less work than it sounds like because the runtimes for frameworks like react and vue are tiny.

Reimplementing react seems to be a rite of passage these days for a lot of people and doing that in Kotlin doesn't sound like it should be that big of a deal. You might be tempted to just use the DOM directly and people do that as well. State management when you have proper data classes, co-routines, channels, etc. becomes a whole different game than throwing balls of untyped json around via global variables.

IMHO this is actually true for typescript as well. The next logical step for typescript would be to cut loose from its js legacy and start having it's own frameworks.

React in Kotlin sounds stupidly simple. I’d very much like this, but we can’t really change our whole app from Typescript now anyway.

That is usually the outcome of not using platform languages, semantic mismatch with the platform, not able to use the libraries without some kind of FFI or wrapping code, needing extra tooling for debugging.

TypeScript gets away with it, because it follows the C++ Trojan route, without the type annotations it is just JavaScript.

Do you think Blazor is doomed to fail because of this?

I don't think so.

Blazor is the new Silverlight.

I might be very critical of how WebAssembly gets sold, but one thing is certain, unless browser vendors decide to rip it off, with WebGL/WebGPU + WebAssembly, a few of us will be getting our beloved Flash, Silverlight, Java back, even if in different kind of clothing.