Making JavaScript touchpoints/interrop entierly optional is my hope as well middle term. One of the main interest of Wasm support for Kotlin is that it allows to avoid the "stay in the shadow of the platform language" unsolvable issue we see on JVM serverside with Java and on the Web with JavaScript/TypeScript. Also avoiding to be exposed to JS ecosystem complexity by default could be a strong booster for Kotlin/Wasm adoption.
This is one of the reasons why I push for getting WASI support in Kotlin/Wasm at some point. But to realize that vision, and if we take the assumption the Kotlin team will be up for this, I think we miss a few building blocks, so leveraging Node/JS ecosystem partially seems needed for now.
In order to make that possible, I think we would need in Kotlin/Wasm:
• WASI Preview2+ support via
KT-36172, see
WASI roadmap
• WASI Component Model support (I created
KT-56605 related issue)
• Gradle support for fetching dependencies from a
(I created
KT-56607 related issue)
And we need WasmGC support in at least one of the major pure WASM runtime, IMO to be significant enough that should be available on Wasmtime (see
wasmtime#5032). Could also happen via WasmGC to Wasm translation in Binaryen, see
binaryen#4590 related issue.
Those topics will move fast in 2023 so we are at a point where this is the perfect timing to begin to consider them and maybe have an influence on their design to make sure they are a good fit for Kotlin and that Kotlin/Wasm becomes a major player in that game.