Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably.

Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level, so even runtime language VMs can run in such a model without harsh slowdowns. While this literally offers fewer features than the JVM, it doesn't restrict which features the final runtime can implement.

This of course is all based on the assumption that you have a CPU-level environment that already bootstraps what you need (like C-based garbage collectors running underneath your dynamic language); or that you're running low-level, assembly-style code for speed reasons.

Unfortunately, as a side effect of it supporting only one memory model, it means that the host code only has a giant memory bag to work with, meaning it needs to reconstruct objects from a giant heap. Currently, anything involving more complex host interaction (say, handles to kernel objects like files) is punted on to either the host-bindings proposal (which has a number of issues and basically was agreed was not a way forward) or the GC proposal (which has even more issues).

The current plan for the GC proposal is to allow skipping having memory heaps at all and talk about things in terms of an object graph and types. See comments here: https://github.com/WebAssembly/gc/issues/32

The important part of a runtime to me is the object model, and wasm basically punted on one for now.

Yes, that's what a CPU-level model with byte-level access means, and is how all code running on your computer has its basis. Whatever high level constructs you want are built on top of your asm-level runtime. This is as-designed, as is the only reasonable way to allow different language paradigms to run on top of it. It's also heavily implied by the name.

It does have a notion of function imports & exports, so in the same way it allows you to do what you want, without specifying what you're going to do. For untrusted code, like in a browser, the environment can choose only to extend limited access. For trusted code, the environment can give access to more OS-level functionality. By webasm not specifying what functions to bind, but giving the ability to bind functions, it remains flexible and appropriate for wildly varying deployments.

A generic object model will be a poor fit for many languages. I hope they keep it simple and low level and don't build in an object model. I'd rather have low level features that let you implement your own GC than a built-in object model. If you have zero cost exceptions and multiple function entry points you can implement your own GC, and coroutines and various other constructs without any more overhead than if you were compiling directly to machine code.

Basically, zero cost exceptions let you unwind and capture the stack while not slowing down the common case, and multiple entry points let you build the stack back up without compiling a large amount of duplicate code. This gives you arbitrary stack manipulation without explicit stack manipulation support in the VM. It enables features that usually require special VM features, such as GC, coroutines, lightweight threads, (delimited) continuations, effect handlers, C# style async.

Thanks for this comment! Very informative, and not something I would have found otherwise.

> Java's intent was "write Java code once, run anywhere". The JVM exposes a strict Java-centric view of what it can run, and it can be difficult to run other language environments on top of the JVM reasonably.

> Webasm is basically "write any code once, run anywhere". It models a very low-level CPU-like environment that the code fully controls at the byte level [...]

The only real difference between the JVM and WASM is that the JVM came from the academic world of "stack-based VMs are better" while WASM comes from the world of "register-based VMs are better".

Both have the same limitations that all the other VMs have. And languages are equally difficult to port to either of them.

What WASM has (and the JVM always lacked) is a compatible zero-friction VM installed on more or less every computer of this planet.

This is the _"everywhere"_ that Java and the JVM wanted but never had.

Wasm is stack based too. The way data flow is encoded is not so important. A compiler can easily generate code for either a stack machine or a register machine. The VM will decode that into SSA again, so it only matters insofar as the representation has to be compact and fast to decode.

The main difference is that the JVM has a garbage collected heap and high level instructions for OOP, whereas wasm is lower level than C and only slightly higher level than assembly. Instead of an object model with GC you have raw pointers.

Basically mainframes execution environments.

Another major difference to Java is that WASM doesn't come with any library whatsoever (as already implied by some sibling comments). The only interfaces to the outside world are function callbacks and shared memory. Callbacks have to be set up manually when loading the code into the VM.

While this makes integrating WASM code into applications a little awkward—you're basically down to peeking and poking addresses in memory, see [1] for some code I wrote that does exactly that—this has some key advantages.

First, the WASM designers cannot make any opinionated decisions regarding what a library should look like. Providing a library is entirely up to the particular toolchain you're using (e.g., Emscripten, which provides a partial libc). And it's up to you what toolchain you use (if any). Second, this facilitates perfect sandboxing. All you're doing is placing your input on a sliver of memory, running your program on the virtual WASM CPU, and reading back the result from memory (and/or responding to callbacks).

[1] https://github.com/astoeckel/linprog2d/blob/b557f69d00dcadfe...

You are correct, but this time, all industry leaders cooperate instead of competing: https://webassembly.org/ (see browser support). Also implementation in browsers is different (more "close to the metal" let's say) and the whole web platform has evolved a lot, and that changes a lot of things.

>(more "close to the metal" let's say)

I don't think that's really fair to say at all.

I would say that JVM bytecode is significantly higher level than WebAssembly, no?

Not really, lot of parallels actually. But it does have higher level constructs than WASM currently has, but they are quite specific to Java the language. So I wouldn't say higher level, just more and larger scope currently.

Yes, and the whole browser<->plugin and plugin<->applet communication layers are missing, WASM runtime is embedded directly in V8 so the WASM code literally is ran closer to the metal.

WASM runs directly on V8, which runs natively.

Bytecode runs directly on the JVM which runs natively.

I'm not seeing how eithers closer to the metal.

JVM yes, but when Java web apps were popular, there was a communication layer between the JVM application and the JVM support plugin, and then between the plugin and the browser.

I think the large difference here is that the VM for WASM is much thinner.

Java was not then and still isn't today the fastest of languages. I think WASM's model of being a lower level VM is going to produce fantastic results. Heck I "ported" Lua to WASM[1] and it was pretty snappy compared to what I was expecting.

[1] https://github.com/vvanders/wasm_lua

The major difference I'd say is that we're not trying to cram a desktop solution into the browser. Java is great but Java apps are not designed like websites, they are not designed to be downloaded one page at a time and they have totally different security models.

Other things like the browser being able to prewarm the vm and other first class citizen type support will hopefully lead to more success.

Java was a language. They created a platform-independent bytecode associated with that language, but it was closely associated with the language itself. Webassembly is much more of a portable version of ordinary binaries.

That's a completely fair question. I believe it's mainly just that Java bytecode is optimized to run on the JVM whereas WASM is optimized to run on CPUs. https://github.com/WebAssembly/design/issues/960

Java bytecode is tightly coupled with the JVM.. it doesn't make sense to consider one without the other. There's bytecodes such as invokevirtual or invokeinterface which don't make sense unless you have Java objects and classes.

The benefit of WASM is that it's more general purpose because it's lower level. It's agnostic to your memory model, so you can have a not-Java object model if you want.

No, Java wasn't the first.

Bytecode formats for application executables delivery was and still is a common practice in the mainframe world.

Xerox PARC workstation, UCSD Pascal systems, IBM and Unisys mainframes as examples.

Haha! WebAssembly is a really simple spec. I’d say optimized for speed and low level simplicity. You could put the entire byte code spec on a single piece of A4 and you wouldn’t have to squint.

It literally is a fancy turning machine bytecode that anyone can write an interpreter/transformer to actual cpu bytecode if needed.

As more languages support WASM, I bet we’ll see more of the front ends written in other languages.

WASM is to the web what JVMBC (java bytecode) is to apps. The open java spec flourished a big ecosystem like Adobe coldfusion/railo, jython for python, Nashhorn/rhino for JS, Jruby for Ruby, Jphp for php, cscjvm for C# and a host of others.

In my university, my compilers course assignment was to write a subset of C compiler that would output java bytecode. It really made me love compilers and programming languages.

I predict a bright future for WASM

There are other bytecode formats even simpler, UCSD Pascal P-Code for example.

The only big difference is that, like many other "modern" ideas, mainstream computers are catching up with mainframes.

"But Java - AFAIK - was the first language that aimed for platform-independent bytecode + network delivery of code (Applets, Webstart)."

Oberon had that too to some extent -- at a time when the Internet was still in its infancy. Oberon wasn't a commercially viable platform though.

Not only was the JVM java centric, the VMs were not high quality across all platforms, and OSs did not come with them.

Also the canvas, webgl, webrtc, audio and video IO APIs that can hook into it are much better than anything Java had to offer.

> Is this an IT thing, or is this phenomenon known in other areas, too?

This phenomenon is certainly known in fashion and, looking at the boom of populist and nationalist politicians around the world, most probably in politics too. I would even risk saying it's imprinted in human nature.

I would say a big difference here is that WASM is designed from the ground up for sandboxing, rather than it being added in after the fact like applets.

While Java has its failings, sandboxing was not an afterthought. Java was designed from day one to be secure-able - with pointer safety, array index safety, the SecurityManager object, classloader security rules, signed applets, etc. (Whether Java actually achieved the security it claimed is a different discussion.)

That's the thing though. Java's "safety" began and ended as a bullet point in a powerpoint presentation. Not for not trying, but because the API surface is so big and the VM so abstract that they made it impossible for themselves to actually deliver sandbox-level security. To compare, js is tiny, has had thousands of man-years poured into it's security, and its customers prioritize security above everything else, and there are still exploits found in every engine every year. Java's security surface area is enormous in comparison, it has a fraction of the man hours dedicated to sandboxing it, and many of it's customers don't even care if the sandboxing is airtight. You can read through the full webassembly spec in a couple hours.