JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers.
And it was almost perfect (modulo hoisting, semicolon omission) for that.
The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client.
Ideally we should have something like <script type="binary/bytecode"> with something close to JavaVM and HTML DOM exposed to it. At least 15 years ago. So we would have a lot of compilers, static compilation and code analysis.
Instead we have tons of weirdest possible solutions: Web "threads" with code that need to be downloaded and compiled before running, that ugly WebAsm, transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose nightmare that bright idea was born?
Yet we have crowds of talented people wasting time of writing about how to really HACK the platform that was not meant to be used this way.
Create bunch of problems to ourselves just to overcome them heroically. Far from being productive.
> something close to JavaVM and HTML DOM exposed to it
> ugly WebAsm
WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.
> 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).
And it was almost perfect (modulo hoisting, semicolon omission) for that.
The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client.
Ideally we should have something like <script type="binary/bytecode"> with something close to JavaVM and HTML DOM exposed to it. At least 15 years ago. So we would have a lot of compilers, static compilation and code analysis.
Instead we have tons of weirdest possible solutions: Web "threads" with code that need to be downloaded and compiled before running, that ugly WebAsm, transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose nightmare that bright idea was born?
Yet we have crowds of talented people wasting time of writing about how to really HACK the platform that was not meant to be used this way.
Create bunch of problems to ourselves just to overcome them heroically. Far from being productive.