All the examples in <https://github.com/JetBrains/...
# compose-web
a
All the examples in https://github.com/JetBrains/compose-jb/tree/master/experimental/examples, are using
Copy code
kotlin {
  js(IR) {
    browser()
    binaries.executable()
  }
}
instead of
Copy code
kotlin {
  wasm {
    browser()
    binaries.executable()
  }
}
this seems a bit off
o
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.
a
You'll keep both wasm implementations in both k/js and k/wasm targets??
whats the benefit of doing so??
o
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.
a
Sorry for my vaguely put question. But thanks for answering it super well
I was actually asking about compose-web-canvas, and you answered that perfectly