| > WASM proved to be secure and JVM did not. This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM. Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only). But worst of all, it just felt jank. It wasn't really part of the page, just a little box in it, that had no connection to HTML, the address bar & page history, or really anything else. The Javascript model rightfully proved superior, but there was no way Sun could have achieved it short of building their own browser with native JVM integration. Today that looks easy, just fork Chromium. But back then the landscape was Internet Explorer 6 vs the very marginal Mozilla (and later Mozilla Firefox) and proprietary Opera that occasionally proved incompatible with major websites. |
For example, Java was the first mainstream language with built-in threading and that resulted in a pile of concurrency bugs. Porting Java to a new platform was not easy because it often required fixing threading bugs in the OS. By contrast, JavaScript and WASM (in the first version) are single-threaded. For JavaScript it was because it was written in a week, but for WASM, they knew from experience to put off threading to keep things simple.
Java also has a class loader, a security manager that few people understand and sensitive native methods that relied on stack-walking to make sure they weren’t called in the wrong place. The API at the security boundary was not well-designed.
A lot of this is from being first at a lot of things and being wildly ambitious without sufficent review, and then having questionable decisions locked in by backward compatibility concerns.