Optimizing WebAssembly+JavaScript mixed applications

[jfbastien]

Some developers have huge applications which today cross-compile to JavaScript and call to hand-written JavaScript code. With WebAssembly they would ship as WebAssembly+JavaScript mixed applications: lots of WebAssembly, calling to JavaScript libraries which communicate with the rest of the Web platform.

I've heard from them that dead code stripping and global optimization across the WebAssembly+JavaScript API boundary is a huge requirement for them: a lot of their code is reused (both transpiled to WebAssembly as well as JavaScript), and the gains they get today from such global optimizations are very significant.

We haven't discussed doing this before because we assumed the API to JavaScript is a pretty static thing. At least for these developers it's not.

We should consider writing a tool which can optimize such usecases (or letting the community implement it).

[kg]

This is part of why I think considering JS glue code/wrappers as potentially a part of a webassembly module is important (#119), fwiw. I care about scenarios like this with my personal compiler.

The question of optimizing across multiple modules, or a mixture of JS and wasm is interesting. Doesn't this overlap a lot with dynamic linking, which would put it past the MVP?

[DiamondLovesYou]

@kg if it was implemented with dynamic linking, the developers that @jfbastien mentioned wouldn't be able to optimize across the WebAssembly/JS boundary.

Presumably, those developers would have to package the wasm && JS together. The dead code elimination ties the wasm to the specific JS code anyway.

I think supporting API implementations with JS (ie wasm -> JS APIs)would be more trouble than it's worth for MVP. Applications should be able to use pure C/[insert prefered language here] to access all the browser provided APIs. That said, I think wasm applications should be able to define their own APIs that JS can use, ie JS -> wasm: ie VLC providing video/audio media playback for formats the browser doesn't natively support.

[DiamondLovesYou]

Let me rephrase: once post-MVP, GC/DOM Integration would allow wasm -> JS APIs, however until then, any wasm -> JS solution would be suboptimal.

[lukewagner]

@jfbastien Glad to hear about all those internal use cases! This sounds a lot like a concern @kripken was raising with Emscripten back when we were discussing the new wasm LLVM backend. IIRC, the issue is that the total size of the impl of various wide APIs (say, GL) is pretty big but only a subset of the APIs are used. So are you imagining some final DCE step in static linking that builds a reachability graph including both wasm and JS?

[jfbastien]

@lukewagner Yes, that sounds about right.

[lukewagner]

We should certainly work for aggressive dead code stripping in our tooling, but I don't see any specific issues to be resolved here with the WebAssembly design defined by this repo.