> Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning?
We'd be ranting at JVM for not having the features necessary to compile high-perf C code into it, for one.
Which is why Wasm is fundamentally a better approach. It's that one case where it makes sense to go as low level as possible (while retaining cross-platform support), to allow as many future possibilities building on this foundation as possible.
Fair, but do we really need C levels of performance on the web? That's madness. They are mostly CRUD apps for God's sake. They don't have to be able to run liquid simulations at 200FPS.
IMO the level of Java / Erlang performance is, and should always be, plenty enough for the web.
For CRUD apps, JavaScript is plenty perf-wise already. The reason why there have been many attempts to push things further is precisely because people are trying to build web apps that need more (including 3D games even).
"Essentially" is a nice word. You can use it for example as JavaScript is a programming language, essentially, yeah.
W3C DOM was defined initially in terms of Java interfaces.
Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning?
<script type="binary/web-bytecode" src="myapp.class">
Today we might discuss -strip-dead-code option in your favorite compiler of XYZ language. Instead of fighting with would-be-linker npm.