Dual wasm + JS builds with wasm2js?

[juj]

Does enabling WASM2JS change the way that the Wasm code is generated?

That is, would it be possible to have one build call generate both JS and wasm code, and in generated html, choose the appropriate target based on the browser in question?

In other words, does enabling WASM2JS impact the quality/executability of the intermediate .wasm file as wasm? (like fastcomp's wasm target did - the generated temp asm.js content was not good asm.js)

[kripken]

That almost works today, there is a MAYBE_WASM2JS in the settings, and see the test_maybe_wasm2js that it links to. Basically, if you compile with that then it will include the extra JS that wasm2js needs. And then there is a script that modifies the JS a little.

The modifications to the main JS file do mean you currently need 2 separate JS files, but see the modifier script tools/maybe_wasm2js.py, those are extremely minor. We could probably make it an option on the Module object, so the HTML could do it.

(So far I just used this for debugging, so that wasn't a priority.)

[juj]

So basically the .wasm file that is fed to wasm2js is the same fully optimized .wasm file that would be run otherwise if not building with wasm2js enabled?

[kripken]

Yes, there is no substantial difference. However I think we do separate out the data segments, so the data is in a .mem file. I also see we disable minification of the wasm import and export names currently (but that should be fixable). Otherwise, the core optimizations we do on the wasm are all identical, there is no concept of an "asm.js subset" which limits asm2wasm in this area. wasm2js is designed to support conversion of arbitrary wasm.

[juj]

That's great! I hope we'd then be able to do dual JS + wasm builds by issuing one emcc call that would generate both, along with the needed .html loader.

Looking forward to testing this kind of scheme out on MINIMAL_RUNTIME.

[sbc100]

Can I ask why you care about the JS build? I'd like to avoid putting effort into the JS build if possible. I'm hoping it can be super niche feature that sees less and less use over time. So I don't think we should prioritize making it easier to use :) I could be convinced otherwise of course... are there use cases I'm not aware of?

[vvuk]

Mainly to support older browsers that don't have wasm support (generally on older mobile devices). It's somewhat niche at this point, but the number of such devices is large.

[sbc100]

Really? What kind of devices or operating systems have non-wasm browsers in them. Can you point to any stats? My impression is that iOS and android devices pretty much universally support wasm MVP at this point.

[juj]

Authored first step towards dual Wasm + JS support in #10118.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.