I'm quite excited about WASM (as I was, admittedly, about Java Applets in the 90s), but this is a question that haunts me. I wish someone with better understanding of WASM and Java than me could write up why byte code delivery to a sandboxed VM in the browser failed in the 90s and why we should believe it will succeed now, or what exactly WASM brings to the table that Java didn't.

I think it mainly failed because Sun basically abandoned it. Security was not the issue I think (Flash was the same, maybe worse, still widely used) but the UX was quite terrible and never really improved: You had the jvm with its long startup times which was more than noticeable in the 90s and early 2000s. Applets always felt very alien inside a Website and using the applet simply to call into optimized code from JS was, while possible not really what it was used for.

Security maybe more of an issue today but WASM probably is not worse than JS in that regard (basically it's just another turing complete language). As others have said APIs are more problematic, which I suspect will ever get worse while browsers further and further try to transform from document viewers to application runtimes (think of such "brilliant" ideas like WebUSB). WASM is not the key issue here, it's running untrusted code on the client which, even if it's sometimes not outright harmful takes control away from the user in one way or antother. In the end the main difference is that it's now a feature of the Browser rather than a plugin which has a hard time to fit in nicely.

Virtual machines tend to take a while to initialize, for Java in part to verify the code.

If it were just the bytecode then it would not have failed. JVM bytecode and WASM have plenty of similarities. What cost Java is the stdlib surface area and security model. Also that it is a separate runtime was annoying, like Adobe with Flash, there was one primary vendor.

So many JVM bugs and a huge stdlib. WASM has no real lib, and when it does, it's security model is already restrictive... there's no disk, network, threads (yet), etc.

Along with the other responses, the JVM imposes its own object model on any language implemented on top of it. WebAssembly does not, so it is vastly simpler and more flexible.

For example, you had to rewrite your apps to run as Java applets. You do not have to rewrite things to run on WebAssembly- all the existing C, C++, etc. code is compatible, up to the platform API.

This is of course assuming that the WASM GC proposal doesn't require a specific object model to get host GC interop.

So far it doesn't look like it will: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."

A big reason Java failed was that it was painfully slow. Starting the VM and importing everything took tens of seconds on old machines, and still takes a couple of seconds on new ones.

Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process.

I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.

>I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.

WebAssembly in browsers executes similarly to javascript in the same sandbox with the same platform APIs with the same kind of delivery methods, so I don't think we have that to worry about.

That's very much the question indeed. All that's really needed for a native experience on both Android and iOS is a native ARM binary, optionally bundled with webkit, but then that's what native runtime environments for Android and iOS have already built-in.

Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).

> Java only had one closed source implementation...

This is not true. There were alternative implementations from very early on, most notably the Microsoft one.

> ...and had many security issues during its life.

True, but WASM hadn't had much of a life so far, so we will see.

> And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).

From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1].

Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on.

[1] https://kripken.github.io/emscripten-site/docs/porting/conne...

> most notably the Microsoft one.

My bad. However it was closed source too, and abandoned rather quickly.

> True but WASM hadn't had much of a life so far, so we will see.

It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code.

> from what I see I think it's ugly as well

Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour.

> Java was designed with a sandbox and a bytecode verifier from very early on.

They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.

> The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy.

> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.

Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will.

[1] https://web.archive.org/web/19980214233937/http://java.sun.c...

"functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.

And how much of that is true today?

All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).

It's still ugly

It was so ugly

After some time you realize: The hype train is traveling in a circle.

Spiral?

Java never had, or tried to have, binary portability.

"Write once, run everywhere" was literally the motto of Java. Java bytecode does run everywhere there is a JRE and the JRE has been ported to a lot of hardware.

Java bytecode is 100% portable.

Java 8 still has syntactic sugar for generics?

What does syntax sugar have to do with binary portability? Generics information is available in the bytecode, and you can access it through reflection (it's available on methods and fields).