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.

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.

Why was this downvoted? I found this quite informative.

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.

It's not an increase in obscurity though: 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).

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

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.

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).

Parse time is basically free with WebAssembly

Smaller than JS, faster, uses Abstract Syntax Trees... sounds like the Juice project. Oh, how much better web apps could've been.

https://web.archive.org/web/20000830093908/http://caesar.ics...

Wow, I never heard of Juice before. It sounds really interesting. Sort of a shame how things turned out in hindsight.

Except with C++ instead of Java and the DOM instead of Java API's.

That doesn't sound like an improvement.

Well, considering it was:

- 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 was very much there, and I'd sooner eat my cat than go back to that era of Java. But C++? Is that really the best we can do? Everyone's so afraid of breaking backwards compatibility but I don't see any other way out of the never-ending accretion of hacks Eich left us with.

Not C++ per se, but anything that can compile to WebAssembly, which should right away include anything with an LLVM toolchain, and should down the line include any compiled language for which someone puts the work in to add WebAssembly as a compile target.

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.

Rust in the browser?

It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.

Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.

At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues.

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.

Not sure if serious... This comment translates to "except without garbage-collection, and with a loose set of inconsistent and constantly-changing interfaces instead of One Sanctioned Spec."

Not sure why you think a GC is a good thing. Deterministic object disposal is to me way more convenient and safe than a GC (haven't you ever experienced a race when the GC dispose your memory too soon or not soon enough?)

There are definitely reasons for manual memory management to still be a thing, but if a GC disposes of memory "too soon", i.e. when there are still live references to the memory, then it is a bug in the GC or in some FFI code that didn't manage interaction with the GC correctly.

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.

If you're hitting race conditions based on when GC runs, I'm pretty sure you're doing it wrong. Java does deterministic destruction of resource-holding objects via try-with-resources, not GC.

Deterministic object disposal is quite easy to do in GC languages, provided they support higer order functions.

It is no different than imposing a programming pattern like RAII.

WebAssembly is about as close to Java applets as Flash. I can recommend the video that was linked by corysama to get a fuller picture of the WebAssembly design.