I think you have a different framing of the problem most people excited about WASM have. It is not about talking directly to the hardware, just getting speed gain like you are. So this component idea seems to be coming from out of the blue and indicates to me you haven't paid webassembly much attention until now.
Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't need to match perfectly, it just needs to be similar enough, minimalistic and better than what we have now. The 'simple enough' part makes translation to native machine code easy enough and the minimal makes it easy for standards adoption. As for beating what we have now, you should read the article, because right now its javascript or nothing at all, and anything even vaguely more like a real machine can be optimized better than javascript.
Also, currently Chrome and Firefox support it. Currently Edge and Safari both support it in preview versions of the browsers. I am not sure where you are coming when you say "there is hardly an agreed-upon standard so far" because the four largest browser manufacturers have agreed enough to have 4 different working products or demos. Perhaps you could expand on that to let me know what you or if your information might have been old.
For example, I just googled briefly for the Chrome WASM platform status and to quote directly, "WebAssembly is in the early stages of language and spec design."
Although I would love to have a working model of WASM to play with, the fact is that it is a fresh idea and that any spec you see today will not be around in five years.
Wanting WASM to look like C/C++ is so hilariously misguided that I wonder if any programmers have been paying attention to language evolution in the past 5 decades.
Yes, Javascript is the best we can do at the moment, and that is truly sh. I do not disagree. My latest progress with regards to that is using something that compiles to JS, but there is still the indefatigable issue of having to use Javascript.
To me, WASM is an initiative to redesign the language behind the screen, and anything short would be inadequate because Javascript already does almost everything, just in an incredibly roundabout, piecemeal, poorly evolved way.
So, you are right in assuming I have not been paying attention to the news in the world of Web ASM, but I must also appeal to your logic and say that any of the news you read now is just theoretical debate. Maybe I should take up my issues with the language designers, as that may prove more fruitful.
Last night I tried a web assembly demo of Ogre3d, an open source 3d rendering engine. It worked in Chrome and Firefox. (I will put the link here after work, it is sitting in my personal email)
Whatever you are reading about the spec is not lining up with the reality of progress. We have two implementations now.
I encourage you to read the article, it is a decent primer for someone with your apparent level of knowledge. I assure you web assembly is not an attempt to replace javascript or make javascript look like C/C++, though you imply you believe such when you say things like "Wanting WASM to look like C/C++ is so hilariously misguided". I am not sure how language design factors into, if someone were so inclined they could compile JS to Wasm and have similar performance gains if the compiler optimized well.
Wasm is about nothing more than performance and they have nailed it. It is very fast compared to javascript, though it is slower than the C or C++ compiled to a native executable.
Getting a bytecode that works more like common real machines will be a real performance boon. It doesn't need to match perfectly, it just needs to be similar enough, minimalistic and better than what we have now. The 'simple enough' part makes translation to native machine code easy enough and the minimal makes it easy for standards adoption. As for beating what we have now, you should read the article, because right now its javascript or nothing at all, and anything even vaguely more like a real machine can be optimized better than javascript.
Also, currently Chrome and Firefox support it. Currently Edge and Safari both support it in preview versions of the browsers. I am not sure where you are coming when you say "there is hardly an agreed-upon standard so far" because the four largest browser manufacturers have agreed enough to have 4 different working products or demos. Perhaps you could expand on that to let me know what you or if your information might have been old.