WebAssembly shouldn't be for the end users to use, it should used for implementations of other languages so they can access the same APIs Javascript can.
Add Lua to the browser, add Perl 6 to the browser, etc. There are plenty of decade old W3C specifications that never made it to the browser properly, like XSLT 2.0, XQuery 1.0, XForms, never mind the latest versions of the specs.
I don't see how it can be feasible to use it for implementations of other languages that don't directly map to webassembly like C. You would have to ship a runtime for the other language along with your application code. The runtime will be either huge with long startup time or small but too slow to be feasible.
Whichever it is it can't be worse than implementing other languages in Javascript directly or using stuff like GWT and there are plenty of those already (including development for running Perl 6, btw).
Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached.
> Runtime for a few selected implementations should be very well be packaged or installed along with the browser itself. Failing that, it should be cached.
Web Assembly isn't related to this. You can standardize on a new language VM that browsers should ship, like was attempted with Dart. What Web Assembly enables is more efficient VM with better interop to Web APIs than currently is possible, but the most prohibitive thing will not change (having to ship multi megabyte VM along with your application code).
Add Lua to the browser, add Perl 6 to the browser, etc. There are plenty of decade old W3C specifications that never made it to the browser properly, like XSLT 2.0, XQuery 1.0, XForms, never mind the latest versions of the specs.