It is really too bad that at some point in the last 18 years of Java VMs being in browsers that they didn't formalize the connection between the DOM and Java so that you could write code that interacted directly with the DOM and vice/versa in a mature VM that was already included. Would have been way better than applets, way faster than Javascript and relatively easy to implement. The browsers actually have (had?) APIs for this but they were never really stabilized.
There are several important lessons to learn from the Java bytecode format and members of the WebAssembly (including myself) do have experience here. In particular, JVM class files would be a poor fit for WebAssembly because:
1. They impose Java's class and primitive type model.
2. They allow irreducible control flow.
3. They aren't very compact. Lots of redundancy in constant pools across classes and still a lot of possibility for compression.
4. Verification of JVM class files is an expensive operation requiring control and dataflow analysis (see stackmaps added in the Java 7 class file format for rationale).
5. No notion of low-level memory access. WebAssembly specifically addresses this, exposing the notion of a native heap that can be bit-banged directly by applications.
Back when Java Applets were a thing, Sun wasn't friendly with browser makers. JavaScript was a gimmicky alternative that was created by a browser manufacturer. It had the foothold, and it grew.
