3 ms·

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. Java Applets were comp

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. 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.

wbillingsley 11y ago
There was a JavaScript to Java bridge in most browsers -- you could simply write a JS event handler that called a public API in your applet. 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.
- asdfologist 11y ago
  Why was this downvoted? I found this quite informative.
awqrre 11y ago
There is no reason to use a binary web format if your only concern is fast web loading...
- azakai 11y ago
  A binary format can help tremendously with fast web loading: 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.
  - hackcasual 11y ago
    Parse time is basically free with WebAssembly
  - awqrre 11y ago
    not worth the jump from open to close... a large margin when most pages already load almost instantly will go unnoticed by most people. 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).
pippy 11y ago
The example in article had went from a GZIPed size of 4.1 MB to 3.0 MB. For the massive increase of obscurity the transferal optimization trade off isn't that great. But it's a double edged sword, I'd also wager obscurity would entice larger AAA game developers to start targeting web.
- k3d3 11y ago
  It's not an increase in obscurity though: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... 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).

wbillingsley 11y ago

There was a JavaScript to Java bridge in most browsers -- you could simply write a JS event handler that called a public API in your applet. 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.

asdfologist 11y ago
Why was this downvoted? I found this quite informative.

awqrre 11y ago

There is no reason to use a binary web format if your only concern is fast web loading...

azakai 11y ago
A binary format can help tremendously with fast web loading: 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.
- hackcasual 11y ago
  Parse time is basically free with WebAssembly
- awqrre 11y ago
  not worth the jump from open to close... a large margin when most pages already load almost instantly will go unnoticed by most people. 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).

pippy 11y ago

The example in article had went from a GZIPed size of 4.1 MB to 3.0 MB. For the massive increase of obscurity the transferal optimization trade off isn't that great. But it's a double edged sword, I'd also wager obscurity would entice larger AAA game developers to start targeting web.

k3d3 11y ago
It's not an increase in obscurity though: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... 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).