How fundamentally different would that be from what Flash or Java were doing? You lose HTML/CSS as your universal, open GUI on the web with all it's built-in advantages (SEO, hyperlinking, accessibility) in favor of some byte-compiled GUI using canvas to draw itself.
In theory it is more secure than Flash and "more open". Flash was bad because it was a security nightmare even "sandboxed" and the player was closed source. Nothing prevents either ActionScript or Java from compiling to web assembly though. Flash API are close to Web API so Flash could absolutely export to WASM. Now is Adobe interested in this is the question.
Webasm is not limited to a contained program that only draws to the canvas. It is meant to be able to do computations at near native speeds and be called from javascript.
Flash and Java were not the same thing, they weren't meant to augment slow parts of java script.
There is nothing you are seeing here that could not be done with javascript already, it would just run slower.
> There is nothing you are seeing here that could not be done with javascript already, it would just run slower.
Yeah, but there isn't much temptation to make QT-like widgets on Canvas with JS, since JS is fully integrated with the DOM. While the temptation for web assembly is to do exactly that, and thus the parent question.
The parent question was about how webasm is different from Flash and Java. The answer is that it is fully integrated with javascript and only does what javascript already does, but with faster execution, faster parsing, and smaller file sizes.
'Temptation' has nothing to do with the lack of java and flash similarities, and the lack of being contained to a single component within the page that doesn't interact with the rest of it.