Exciting news about <the present and future of Kot...

# webassembly

[eygraber]

Exciting news about the present and future of Kotlin for Web!

One thing I didn't see directly addressed was whether JsAny will still be needed for WASM. It causes massive headaches when trying to write common code for both JS and WASM, since WASM needs the supertype to be JsAny, and that doesn't exist for JS.

[James Yox]

Sounds rad. I would love to see smaller bundle sizes. Probably my biggest pain point. Decoupling from webpack would be huge. I am hardly a web expert but I know that some of the others listed are considered a lot better.

[James Yox]

I would really like to see the ability to use Compose in partials on web. Right now you sort of have to go all in or nothing with compose based pages. I think being able to embed a single view in a static page or even use some html/css for parts would be really cool as well. It's possible someone has gotten that working since I last checked though.

[Artem Kobzar]

@eygraber with the common source set we've announced, unfortunately there will be still JsAny, however it will be compiled into the regular Any on the JS side (so you don't need to introduce some new types for this common source set)

[eygraber]

So in the common source set we'd still extend JsAny, which will be commonized for JS and WASM? That's gonna solve so many issues I've had 😄

[Artem Kobzar]

Exactly, this is the main idea of this common source set

[Michael Paus]

What about direct Wasm to Wasm interop? If, for example, you want to use some Rust code compiled to Wasm from your Kotlin code you currently have to go through JavaScript interop which is not very efficient.

[Artem Kobzar]

@bashor ^^

[bashor]

@Michael Paus I think if you use only primitive numbers even through JS interop it should be efficient enough. Anyway, if it’s not enough, you can check out annotations for low-level interop -- WasmImport and WasmExport. In the future, we are considering allowing using component model for wasm-js target as well.

[Michael Paus]

It’s the component model that my question was particularly aiming at (although some interim solution is also welcomed). I was wondering why there was no word about this in the blog post above. Is it still so far away? In practice you do not get very far with just primitive numbers as arguments. I am currently serialising complex arguments using kotlinx-serialization-cbor, but having to go from ByteArray to Int8Array and back again seems to involve several undesired copies. This demo, for example, uses the Java Topology Suite (JTS) compiled to Wasm via TeaVM from a Kotlin Compose Multiplatform application. This works (on the latest Chrome and Firefox but not Safari) but the interfacing could be improved. I am also investigating the possibility to use the new GraalVM native-image Wasm backend for that purpose.

[bashor]

I was wondering why there was no word about this in the blog post above.

You know, it’s difficult to cover everything in one post, you always need to make a choice. Also, the post focused on the web (browser) part, while our CM works so far has been focused on WASI needs.

[bashor]

Here is a related issue, feel free to vote or star to get updates.

[Michael Paus]

Just realised I voted for that already like 31 other people 😉.

[turansky]

So in the common source set we'd still extend JsAny, which will be commonized for JS and WASM? That's gonna solve so many issues I've had 😄

@eygraber to avoid redundant noise in common we add JsAny as parent automatically via Seskar plugin for external types without parent types in common source set. 😉

Isolated example you can find here.
Also we build common artifacts in Kotlin Wrappers (like kotlin-browser) with automatic JsAny parent.