The main WebAssembly targets nowadays are:
- wasm32-unknown-emscripten
- wasm32-unknown-unknown without wasm-bindgen
- wasm32-unknown-unknown with wasm-bindgen
- wasm32-wasi
emscripten is causing massive compilation problems for us and I'm close to entirely dropping support for it, if it continues to cause more problems, as we are probably the only ones actually using this target, and even we don't need it anymore. The unknown target with wasm-bindgen should honestly be its own Rust target, but apparently no one cares enough to make that happen, so we'll have to differentiate via a feature. We definitely want to directly support wasm-bindgen, but need to figure out how to get it working with our own binding generator. We'll see how well that goes. We can directly support the wasm32-wasi target without any hacks or anything (although hotkeys would be questionable). This may even open the possibility of dropping the non-wasm-bindgen wasm-unknown target support entirely. Another possibility is downgrading it to essentially what the no_std target does, but with the parsing compiled in (which is not a possibility for no_std atm). Then it's truly an unknown target where we don't do any imports.
The main WebAssembly targets nowadays are:
emscripten is causing massive compilation problems for us and I'm close to entirely dropping support for it, if it continues to cause more problems, as we are probably the only ones actually using this target, and even we don't need it anymore. The unknown target with wasm-bindgen should honestly be its own Rust target, but apparently no one cares enough to make that happen, so we'll have to differentiate via a feature. We definitely want to directly support wasm-bindgen, but need to figure out how to get it working with our own binding generator. We'll see how well that goes. We can directly support the wasm32-wasi target without any hacks or anything (although hotkeys would be questionable). This may even open the possibility of dropping the non-wasm-bindgen wasm-unknown target support entirely. Another possibility is downgrading it to essentially what the no_std target does, but with the parsing compiled in (which is not a possibility for no_std atm). Then it's truly an unknown target where we don't do any imports.