All the examples in <https://github.com/JetBrains/compose-jb/tree/master/experimental/examples>, are...

# compose-web

[andylamax]

All the examples in https://github.com/JetBrains/compose-jb/tree/master/experimental/examples, are using

kotlin {
  js(IR) {
    browser()
    binaries.executable()
  }
}

instead of

kotlin {
  wasm {
    browser()
    binaries.executable()
  }
}

this seems a bit off

[Oleksandr Karpovich [JB]]

k/wasm target has been added in 1.8.20-beta.

The default compose artefacts publication uses kotlin 1.8.0 for now.
I think we’ll keep both targets k/js and k/wasm after 1.8.20.

[andylamax]

You'll keep both wasm implementations in both k/js and k/wasm targets??

[andylamax]

whats the benefit of doing so??

[Oleksandr Karpovich [JB]]

both wasm implementations in both k/js and k/wasm targets??

I’m not sure I completely understood your question.
In case of compose-web-canvas with k/js only skiko is compiled to wasm. The rest (compose-runtime, compose-ui, etc) is compiled to js.

With k/wasm we can compile all compose libs to wasm + use skiko already compiled to wasm.
__
If you’re asking “why to keep compose-web-canvas k/js and k/wasm targets if k/wasm does the same?”
For now, k/wasm requires GC flag enabled in a browser.
Unless keeping and maintainig both targets requires a lot of efforts, I think we would keep both targets.

[andylamax]

Sorry for my vaguely put question. But thanks for answering it super well

[andylamax]

I was actually asking about compose-web-canvas, and you answered that perfectly