Yet, this simple fact that a WebAssembly app needs to download everything its needing to run puts it at disadvantage with Javascript (you download a browser with all the base libraries only once, and that's not lightweight).
For now, WebAssembly apps (in general and not just .NET ones) are more similar to mobile apps than websites, just because of this significant difference.
To put it another way, instead of starting with wrapped native apis and doing wasm last. Start with browser apis and make native ports of those, then you'll get something that works well in the browser and (95% of the time IMO) will work fine in your native version as well.
There's already a plan to give WebAssembly direct access to DOM, and to any other API JavaScript would have access to, without needing a JavaScript shim. (This requires integration between WebAssembly and the JavaScript garbage collector, which is part of why it's taking time to develop.)
Can such a thing even exist?
I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
Yes, cross-language code sharing is being worked on.
> I think we'd better install wasm libraries (both language-specific and language-agnostic) like we install browser extensions.
How would a site know what libraries are available? How would versioning work?
This is a caching problem, best solved at the normal browser resource cache level IMO.