From Java applets to Java applets in twenty years.
Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the single unified DOM and its event model.
Because it uses the DOM, the text and widgets are real. The text is selectable, looks like regular text, etc. Java Applets had their own GUI/widgeting system that looked bad and behaved differently.
Before XMLHttpRequest became reliable across browsers, a fairly common trick was to use a 1 pixel Java applet to do the asynchronous calls to the server, and then call back out to JavaScript to manipulate the DOM.
Java only "behaved differently" if you wanted your applet to paint a square of the screen. Which was more about the problem that browsers also didn't support SVG, so if you wanted an interactive diagram you had to isolate yourself from HTML.
1. Code size can be significantly smaller, reducing download time (even with gzip; tests show a 30% win).
2. Parse times for a binary format can be much faster than for code as text, by a very large margin.
I think that you would see a much bigger performance increase if websites would not load resources from 10 different domains for serving a single web page (you have a much higher chance of getting some unforeseen delay from one of those hosts).
The format is intentionally being built in a way that you can look at the source, in the same way you would look at minified Javascript currently.
If you're worried about obscurity, look at what is generated by asm.js. WebAssembly won't be any worse than that (and is, in fact, more or less a more efficient/correct equivalent to asm.js).
https://web.archive.org/web/20000830093908/http://caesar.ics...
There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc.
If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in.
It's not technology - it is politics.
- isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year)
it does sound as a great improvement. Except in case you weren't there and can't remember.
I’m also hoping it winds up being friendly enough to hand write WebAssembly for small chunks of numerical code. With asm.js, that’s currently kind of a pain.
GC is generally a good thing precisely because it prevents use-after-free errors and enables programming at a higher level without worrying about memory management. There is often a performance cost to this, it's true, but for large classes of programs it's a cost that's worth paying.
It is no different than imposing a programming pattern like RAII.