JetBrains has released Kotlin 1.9.20 beta, including an experimental feature called Kotlin/Wasm that targets WebAssembly. The new release depends on native Wasm garbage collection called WasmGC, which is also at an early stage of development from browser vendors.

Kotlin was already able to target Wasm to some extent, by targeting Kotlin/Native based on LLVM and using the LLVM Wasm support. This older approach, called wasm32 is one of a number of Kotlin/Native targets to be deprecated.

As a JVM language, Kotlin is garbage collected, but until recently WebAssembly has not had native support for garbage collection, requiring any garbage-collected language to come up with its own solution. Wasm-gc is a proposal to fix this, promising “efficient support for high-level languages.” Potentially this can both perform better than custom solutions, and reduce the size of application binaries. WasmGC can be enabled in the recent version of Chrome, Firefox and Edge via browser flags.

JetBrains says that Kotlin/Wasm enables faster compilation speed than wasm32, easier interoperability with JavaScript and browser APIs, faster startup, and faster runtime performance. However there is no IDE support yet. “We provide Kotlin standard library (stdlib) and test library (kotlin.test) for Kotlin/Wasm out of the box,” say the release notes.

Sébastien Deleuze, who works on the Spring Framework at VMware, calls the release a “huge step forward.” He intends to explore full-stack Kotlin development using a Sprlng Boot Kotlin backend and Kotlin/Wasm in the browser. Although Kotlin can also target JavaScript, Deleuze believes there is more future in using Kotlin/Wasm DOM (Document Object Model) APIs avoiding the need for developers to understand both Kotlin and JavaScript development.

Another aspect of this is to target WebAssembly outside the browser using WASI, which provides an API to operating system features including files and sockets. Wasm has promise for deploying microservices to cloud or edge, since the runtime is fast and lightweight compared to container images running the JVM. A snag here is that the Wasmtime WASI runtime does not yet support WasmGC. “For now, the main path to run Kotlin/Wasm WASI applications is to leverage Node WASI support,” writes Deleuze.