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

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.

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

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.

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