Comment by nabla9
10 years ago
Oberon had so many good ideas. It's still worth studying.
The problem in the 90's: provide executable content across the net for browsers.
Java was supposed to provide the portable universal binary code you could load and execute everywhere, except that it did not have the necessary features and was too complicated. Then came Javascript but it was broken mess for long time and needs binary format.
There was Juice back in 1997 http://www.modulaware.com/mdlt69.htm. Ligthing fast single pass compiler that works with AST and gives constant-time type and well-formedness checking portably over the net.
If WebAssembly is ready in 2017, we can finally have the portable binary with the same set of features as Juice 20 years later. Instead of Oberon system, we have browser in the client and node.js in the server throwing WebAssembly around.
It's like déjà vu all over again.
To tie Juice into the modern world of Javascript and Web-assembly:
This comes out of Michael Franz' PhD thesis on Semantic Dictionary Encoding. Franz did his PhD under Wirth, and is now a professor at UC Irvine where he was the thesis advisor for Andreas Gal.
Andreas Gal was instrumental in getting tracing JS JITs of the ground, and until recently served as CTO at Mozilla.
The problem with Java binaries on the client, was that the Java applet didn't have direct access to the DOM bindings.
Instead, the applet rendered it's own GUI via the plugin, and the look and behavior was inconsistent with the rest of the browser experience.
A similar story with activex and flash.
It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked higher-level language that has API access to the native browser event loop and dom components the same way that Javascript does it.
Another problem with Java applets was that they were slow as hell for that time.
> It's a mystery why it has taken so long to get to the point where we can target the browser with a statically-checked higher-level language that has API access to the native browser event loop and dom components the same way that Javascript does it.
We are already there. Compile to JavaScript (or, heck, WebAssembly if that ever becomes feature-complete enough).
I feel it could have been easier to add DOM bindings to Java instead of the path that has been taken.
It was a great project. Still faster than Javascript if run through an optimizing compiler. Combine that with today's best security schemes for browsers and you have a lot of performance for a better level of safety. Not going to happen, though. Not enough overhead & buzzword compliance to make it into a web stack. ;)
I cannot wait to see the future in Birth and Death of JavaScript become true, except for the parts of nuclear war.