Since there isn’t a direct haxe wasm target at the moment, you can target wasm via hxcpp + emscripten: https://gist.github.com/MatthijsKamstra/cbae06ae1dc3561621e489ae4d7a8aab
As you mentioned, since haxe is a GC’d language, hxcpp has to bundle its own GC. If wasm gets a built-in GC it will start to make more sense for there to be a direct wasm target, although if your target is the web (rather than say some other wasm runtime), it’s not clear haxe > wasm is a win over haxe > js.
From a trade-off point of view, the case for haxe > wasm isn’t as big as say rust > wasm or c > wasm. haxe > js has the benefit of interacting with native browser interfaces, data structures and objects directly, whereas interacting with browser apis via wasm requires an awkward method binding interface https://stackoverflow.com/a/40904287. On the web, binary size is critical, so it’s valuable to br able to make use of APIs and data structures already bundled with the browser rather than bundling your own. For compiled languages like C and Rust, wasm is great because fairly similar to their existing binary executable targets so there’s not such an impedance mismatch as there would be compiling C to JS for example. However the cost is wasm binary sizes can be pretty chunky.
What wasm does have on its side is fast math (it’s not orders of magnitude faster than js, but a few times speedup). So the way I structure haxe wasm projects is to write the main app in haxe, then any special-case modules like video encoders are written in C or Rust and compiled to wasm modules which I can call from haxe-js. This way you get the best of both worlds and your binary sizes stay small. However, it’s not that often js-CPU code is a bottleneck so it’s rare that this is advantageous
In the future if wasm gets a GC + trivial native browser API interface then haxe > wasm might bring smaller binary sizes and slightly faster execution
Here’s a website where you can compare webassembly vs js performance. On my mac chrome js seems to often benchmark faster than wasm (weirdly)