Indeed <https://github.com/JetBrains/kotlin/commit...

# webassembly

[sdeleuze]

Indeed https://github.com/JetBrains/kotlin/commit/6e6ffa12a6893b8078986cd3b16c08f41ebb4809 ❤️

[napperley]

Wonder if the changes might indicate extended WASM support, that makes its appearance in a Kotlin 1.4 release.

[napperley]

Looks as though the changes are for a new Kotlin development platform (Kotlin/WASM?). Could that mean there is a new Kotlin development platform that makes its debut in the Kotlin 1.4 release?

[gildor]

I doubt very much that it will be available in 1.4

[sdeleuze]

Yeah that’s just the bootstrap IMO

[sdeleuze]

But still great news

[napperley]

Actually that commit is for adding WASM support to the Kotlin JS compiler (see yole's comment: https://www.reddit.com/r/Kotlin/comments/cvo91h/webassembly_as_a_supported_target_is_coming/ ). A bit surprising that Kotlin JS is getting WASM support. Why is Kotlin JS getting WASM support?

[gildor]

A bit strange interpretation for me.
Different backends for Kotlin are parts of the same compiler, also going to share more logic in future between them
So, because it has own backend and own stdlib, it's new a new Kotlin target platform, even if this platform will reuse parts of another one. It's first platform that can share big parts of tooling with another one and you definitely need a lot from Kotlin JS if you target Wasm for web: interop with js, browser API definition, integration with js infrastructure

[napperley]

With the upcoming Kotlin Conf JB "might" shed some light on the WASM situation in Kotlin 🙏 .

[gildor]

Yes, most probably

[bashor]

@gildor is right, it’s another backend, but it’s not isolated, so of course it will reuse things already done as much as possible, e.g. in the new Kotlin/JS and K/N backends, in K/JS tooling and so on.

[napperley]

Presumably WASM support in Kotlin Native will be extended significantly?

[gildor]

Personally, I don't think that it will be supported, there are some limited use cases for K/N -> wasm, also it already supported by llvm, so probably it will not be dropped, but I don't see why would it be extended. If wasm is your primary target, you definitely don't want to use llvm implementation, if you target MPP than just use wasm as platform. The only valid case for k/n wasm, which I see, is when you have existing k/n only app, that probably uses some C dependencies and you want compile it for browser (and do not use js APIs) or upcoming desktop/serverless/etc wasm runtimes.

[napperley]

Another use case for using Kotlin Native to target WASM is to port existing Kotlin Native libraries to the WASM side.

[gildor]

yes, “existing k/n only app” just should be “existing k/n only project”, so I believe it’s the same use case

[sdeleuze]

port existing Kotlin Native libraries to the WASM side

Kotlin/Native is still very new I don't think that's a wide use case. If you want to port code to multiplue platforms use multiplatform code IMO.

[gildor]

if you use C dependencies it’s another story, but I agree, instead of support rare K/N wasm better focus on K/Wasm