Future of wasm2js

[kripken]

I'd like to do some work on wasm2js. Specifically, the use case I have in mind is to integrate it with Emscripten + the LLVM wasm backend. Then we can use that, instead of the current fastcomp asm.js backend, as a solution for emitting non-wasm output. This would have several advantages:

• Better code: Can benefit from LLVM backend opts, newer LLVM IR opts (since upstream is more up to date), Binaryen opts, and Emscripten wasm-specific opts (metadce). Will still be able to benefit from Emscripten asm.js opts, since those are in passes that run after the backend.
• Faster build times: can optionally use wasm object files for fast linking.
• No more separate bitcode or object files for two different targets.
• Get rid of fastcomp and all the support code for it.

This doesn't need to emit valid asm.js since in practice almost all browsers with asm.js AOT also have wasm anyhow (in fact chrome shipped wasm before asm.js AOT; and firefox did have some releases with just asm.js, but even LTS has had wasm for a while now). So wasm2js is an option here.

Specific work I'd like to do:

• Integrate wasm2js with emscripten.
• Benchmarking and performance tuning. Should be no slower than current fastcomp asm.js.
• Testing (emscripten test suite, almost all features should be supported) and fuzzing.

This may involve changes to the JS emitted by wasm2js, so I wanted to ask how much current wasm2js users care about the form of the output? I know the Rust people have been using wasm2js, but I heard recently they have plans to write something new (which made me sad to hear, but on the other hand fewer users may mean more flexibility in terms of how we evolve wasm2js). cc @fitzgen

[dschuff]

+cc @juj

[kripken]

Some previous relevant discussion: emscripten-core/emscripten#8085

[kripken]

ccing wasm2js/wasm2asm authors for more visibility: @yurydelendik @alexcrichton @dcodeIO @froydnj @tlively

[dcodeIO]

Does this imply that a compiler that doesn't use LLVM/Emscripten won't be able to output a JS version (we don't care about valid asm.js, just something JS) with just Binaryen / BinaryenModulePrintAsmjs anymore? That'd be sad.

[tlively]

I strongly support this direction for wasm2js. Replacing Fastcomp was exactly my goal when I worked on this as an intern in summer 2017, with the motivation of simplifying Rust's dependency on Emscripten.

[tlively]

@dcodeIO, if I understand correctly, that will still work but the JS you get may be different that what it is today. In fact the JS will be better because wasm2js will be feature-complete enough to support all emscripten tests.

[kripken]

Yeah, we definitely don't want to remove use cases people care about - @dcodeIO, thanks for mentioning that you use this code path.

How much do you care about the external API of the JS code emitted? I might want to change it in minor ways. (Aside from that, my plan is to just improve the quality of the JS emitted.)

[dcodeIO]

Not really bound to the external API, as long as it can either be run directly or easily postprocessed. A WebAssembly-ish API, similar to how Wasm works in browsers, would be great though :)

[kripken]

Yeah, a wasm-ish API - almost like a polyfill - is what I was thinking too, heh.

[alexcrichton]

This all sounds like a great idea to me! FWIW the idea that we might implement wasm2js in Rust was primarily motivated that its maintainership here seemed to be waning. If it picks up though we're happy to help.

I'd personally agree that asm.js isn't too important at this point for the reasons mentioned, and the only desire we'd have is that wasm2js emits an ES module (as it does today) for inclusion into apps. Eventually we'd like to include this at least as a default option (if not on by default) in pipelines like Webpack.

[kripken]

Thanks @alexcrichton, good to know! Yeah, I intend to make this a major focus for myself personally, and it will definitely be a high priority once emscripten depends on it as a fastcomp replacement.

I'll have to investigate the JS output format issue - for emscripten and AssemblyScript it seems like a "wasm polyfill" approach is better, and for you an ES6 module is. Probably we can implement one in terms of the other or something like that.

[bvibber]

I have a couple concerns about the "wasm polyfill" approach:

• Will this work with multiple modules? In ogv.js I load separate modules for each file type, and so may have multiple instances of different demuxers running in the same JS context. They need to not stomp on each other if they each load a polyfill for the WebAssembly namespace.
• If the polyfill replaces the global WebAssembly object, other code that's loaded into the web app later may think WebAssembly is available and try to compile and run its own modules, which would presumably fail.

These can probably be resolved by allowing the polyfill to use a custom namespace, and maybe also emitting it as a separate file which can be loaded once.

Note also for my case, JS output mostly targets IE 11 and old versions of Safari and Edge, so I need to avoid ES6 modules.

[alexcrichton]

@kripken that sounds great! And yeah definitely agreed that the output format isn't too too important in that we can translate one way or the other as necessary. I think the polyfill approach is probably more flexible because it's how wasm is always used at the fundamental level today!

[kripken]

Thanks @Brion, very good points. Yeah, the "polyfill" approach does want to affect the global scope. So it seems like building the polyfill as an extra optional layer on top of the other approach is the better way to do.