Hi,
saw some experiments and some libraries that have added ecmascript export for web, but would like to know if someone have managed to build at least some hello world webgl app exported to wasm.
I recall that GC standardisation was stopper for haxe adaption some time ago. Just wanted to experiment a bit with wasm webgl and haxe, and also compare workflow compared to rust.
Any info or maybe some suggestions where to start ? 
Thank you
Hey @Hersir,
Since there isn’t a direct haxe wasm target at the moment, you can target wasm via hxcpp + emscripten: Haxe and Webassemply · GitHub
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)
https://takahirox.github.io/WebAssembly-benchmark/
© 2018-2020 Haxe Foundation - Powered by Discourse
