A lot of web people don't realize magnitude of impact WASM will have on the web.
Well yeah.. it's an assembly language, the sort you inline in your C (or some other) programs to squeeze critical code paths.
Doing your virtualdom or form validation in assembly probably wasn't a core design goal, no matter all the scripters that get so easily hyped about wasm. But consider usecases such as real-time interactively adjustable filters on currently-playing page-embedded media objects, 3d editors that let the user run (non-shader) algos on the current model such as geometry simplification.. all kinds of use-cases come to mind where wasm can really drive richer, faster, more powerful browserbased apps than were possible without it.
It wasn't part of the MVP, but it most definitely is a design goal for future iterations. See: https://github.com/WebAssembly/design/blob/master/GC.md
The other thing preventing the use of JVM or .NET is that porting the runtimes over isn't easy. i.e. You can already run this bytecode in a browser but it isn't widely used. (http://jsil.org/, https://github.com/decatur/j2js-compiler, https://github.com/plasma-umass/doppio, https://github.com/mozilla/pluotsorbet etc)
I already write backends in Go, the hope of writing frontend code in Go is really exciting. All the JS people are going to say, "with node JS is already there", but this misses that I (and a vast number of other developers) hate JS with a burning fiery passion.
Every developer I know hates JavaScript. I think the only ones that like it are honestly people that haven't used much else. Literally everything about the language including tooling and module systems around it is a garbage fire.
I tried to use Node and it gives stupid shitty error messages all the time and blows up if anything hangs for 200ms because it only supports a single thread. It's honestly pretty crap compared to more mature runtimes in C#, Java, Go, Python etc...
I think what's happened is that a bunch of front end HTML guys that only use JS have been introduced to fire water and they're going nuts about it
GopherJS apparently struggles with binary size too [2] (though that's not WebAssembly).
[1] https://blog.golang.org/go1.7-binary-size [2] https://github.com/gopherjs/gopherjs/issues/136
1. without concurrency
2. if GC end up being provided by the execution environment
3. without the need to support networking and file-system (assuming this has to go through JS)
And guess what? I've been doing a ton of web dev over the past 5 or so years and I love it. I use React/Webpack/Node/ES201x/Typescript/etc. It's great.
When you're in a bubble, you like things for the beast you know, and hate things for the beast you don't know. There are a ton of devs out there that do not hate JS, and it sure as hell isn't out of inexperience.
>You're in a bubble.
Come on, I made a qualified statement, I didn't even say most devs.
> I've used QBASIC, C, C++, various .NET languages, Java, Python, list goes on and on. I've led desktop app, firmware drivers, kernel driver, security architecture projects, list goes on and on.
I have a fairly similar history, ASM, QBASIC, C/C++, Java, Go, .NET (C#/VB), Haskell, Scheme, Prolog etc. I have also worked on systems software and applications.
I've worked at consulting firms, fortune 500s and startups and I have to say if you haven't run into my sentiment before commonly, I would assert that it is you who are in the bubble (sorry). I don't think you have to agree with my opinion, but to reject it as being common is absurd.
I don't hate JS out of lack of familiarity, in fact I have spent a lot of time porting node apps to Go and discovering all their terrifying callback spaghetti, concurrency bottle necks and inconsistent typing during single variable lifetime.
If you're going to target the web and need a GC, why not use hand-written Javascript? (or any variant like Typescript/Purescript if you want additional compile-time checks like type-safety/immutability).
If your users only have to download the language runtime once, the idea of using a runtime for a popular language on your site doesn't seem like such a bad idea. Popular runtimes could even be pre-cached and shipped with the browser.
It's meant to provide plug-able, high-performance functions for heavy computational tasks - crypto, game rendering, heavy in-browser data analysis, etc etc.
I double JVM in WASM makes sense at all - though somebody will probably do it in anyway. WASM is not meant to be good at Garbage Collection, etc. It's not a design goal at all.