I am a bit confused about the current state of Kot...

# webassembly

[Michael Paus]

I am a bit confused about the current state of Kotlin/WASM and the future direction. I wonder whether the following use case will be supported with the upcoming Kotlin 2.4.0.

• Have some self-contained library code written in C or Rust compiled to WASM and properly wrapped up as a component with a WIT file, based on the already existing tooling for C and Rust.
• Generate a Kotlin binding from the WIT file and incorporate the library WASM code into a Kotlin module, allowing direct Kotlin to WASM calls without going through any JavaScript code.
• Run this code in a browser, i.e., wasmJs and not only wasmWasi.

[Jim Teichgräber]

Hey there! Thanks for the question and your interest :)

• Have some self-contained library code written in C or Rust compiled to WASM and properly wrapped up as a component with a WIT file, based on the already existing tooling for C and Rust.

• Generate a Kotlin binding from the WIT file and incorporate the library WASM code into a Kotlin module, allowing direct Kotlin to WASM calls without going through any JavaScript code.

Up until this point of the use-case: yes, we hope that this will make it into 2.4.0 as an experimental feature. We already have a dev build available with highly experimental support for that (usage example to play around with today, wit-bindgen fork).

• Run this code in a browser, i.e., wasmJs and not only wasmWasi.

This is where it gets tricky. Unfortunately, no major browsers support the component model as of now, so ordinarily, this is not directly possible from any other language with a component model implementation either. To this end, jco is a bytecodealliance tool to transpile linked Wasm components that use wasi preview 2 (through this package) to JS + a Wasm core module, to be able to run them in the browser. In the overall workflow, this would basically mean replacing the wasmtime run ... invocation, with jco transpile ... and then importing and running the resulting ES module in the browser (writing to wasi:cli/stdout should then be equivalent to calling console.log, for instance). There are still quite a few open questions in this workflow however, as it's still wasi-based in the end.

We are definitely committed to continue working on our support of the component model! Given the experimental state of jco transpilation, supporting that use-case could be tricky. As this all depends on stable and thought-out support for WIT, this will likely be what is fleshed out first, as our current prototype still has quite a few limitations, isn't tested extensively yet, and does not meet our desire for usability, in terms of idiomatic mappings from WIT types to Kotlin types, and general ease of use.

So in summary, the component model support we have available right now is in a very early stage and highly experimental, but we're actively working on improving and extending it! :)

[CLOVIS]

Is there a place for early adopters of the component model? I'm writing a library with Ktor Sockets that I'd like to expose to other languages through the component model at some point in the future. It's all very prototypal on my side, so I'm interested in playing around with the component model in early stages. However, I haven't really had the change to really dive into WASI so far, so I don't really know where to start other than adding the wasmWasi() target in Gradle.

[Jim Teichgräber]

Is there a place for early adopters of the component model?

If you're adventurous, and ready to face some dragons (for there may be a few ^^), then the answer is already yes! The best starting point in that case would be our current wasi-http sample, which implements a small http server. However, as I mentioned, its very experimental, and its build system is a bit, lets say, artful. But it's definitely a place to start from.

That sample demonstrates how to import and export wasi interfaces. For your use-case, it sounds like the main difference would be that you'd have to define the types and interfaces you want to export yourself in wit.

If you do decide you want to go ahead with it, feel free to reach out again with questions!



In a broader sense, we definitely want to encourage early adopters even more at a later, more mature stage, once we've ironed out enough kinks that we think it's ready for a bit of a wider audience. There are no concrete plans in that direction yet, it will most likely just be something that we will promote more once we feel our component model support as a whole is ready enough to be thoroughly scrutinized by more developers 🙃

[CLOVIS]

Do you have recommendations on where to find documentation on how to write .wit files, etc?

[Jim Teichgräber]

The official wit reference is the best guide for quickly playing around with it.

The component model design docs are also a very useful, more in-depth resource.

Other than docs, I found looking at the WIT source of wasi itself very helpful :)

[Michael Paus]

I already did some experiments on my own with the experimental wit-bindgen for Kotlin and after I understood how it works it was usable. In my question above I explicitly said "self-contained" because I know that WASI is not supported by todays browsers. But if you have some code which doesn't need any WASI APIs, then this should work in a browser too, or am I missing something here?

I also already saw a few things which I didn't like so much in the generated Kotlin bindings but I have to dig deeper before I can say anything more specific about this.

[Jim Teichgräber]

> after I understood how it works it was usable
I would actually disagree with you here: this is why we're so intent on emphasizing that the current version is highly experimental. In my opinion (also having tried to use it in a few different cases with both imports and exports to other languages), the prototype right now is not really usable. It might work for experiments, but it still needs a lot of improvement.

> I also already saw a few things which I didn't like so much in the generated Kotlin bindings
This is a perfect example of an area that still needs major improvements, I totally agree. There are a ton of things we still want to change in that regard, which is another reason I wouldn't encourage anyone to use this in anything close to a production setting, as there will most likely still be a ton of breaking changes.

> But if you have some code which doesn't need any WASI APIs, then this should work in a browser too, or am I missing something here?
I am not super well versed in the details of this yet, so take this with a grain of salt, but afaiu: no. The binary representations of Wasm components and Wasm core modules are not the same; for example, they already differ in the version field, so after the 4B magic number, the next 4B already differ between the 2 formats. I.e., this is not a plug and play situation, a component cannot simply subbed in for a core module. Of course, browsers could support a "simple" components case (with no imports in the case of your example) nonetheless (I am not aware that any browsers do), but this is out of our hands. jco is probably your best bet for running wasm components in a browser semi-reliably. But then again, reliability is not something that should be relied upon with the current state of Kotlin/Wasm's component model support yet anyway ^^

[Michael Paus]

The term "usable" is of course a matter of expectation. As I didn't expect much, because I know it's an early prototype, it was usable for me. It didn't work out of the box because already my first example contained some stuff which isn't supported yet, so I had to tweak that a bit, but then it worked. I could create import and export bindings. When I have time again I will continue my journey from there.

[Jim Teichgräber]

Nice! Just as a sidenote in case one of the missing features was world-level functions like

world w {
    import foo: func() -> string;
}

We added support for that just a couple of hours ago :)

[Michael Paus]

It was exactly that :-)