52 ms·

At the risk of sounding like an old grumpy guy[0], isn't this kind of what Java[0] set out to achieve some 20 years ago? I am in no position to compare the two

by krylon 8y ago

At the risk of sounding like an old grumpy guy[0], isn't this kind of what Java[0] set out to achieve some 20 years ago? I am in no position to compare the two by any metric other than age. But I am old enough to appreciate how such ideas tend return every couple of decades. Is this an IT thing, or is this phenomenon known in other areas, too? [0] I am not even that old, and I do my best to not be grumpy. [1] Yes, yes, Smalltalk, too. But Java - AFAIK - was the first language that aimed for platform-independent bytecode + network delivery of code (Applets, Webstart).

TomMarius 8y ago
You are correct, but this time, all industry leaders cooperate instead of competing: https://webassembly.org/ 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.
- jayd16 8y ago
  >(more "close to the metal" let's say) I don't think that's really fair to say at all.
  - conradev 8y ago
    I would say that JVM bytecode is significantly higher level than WebAssembly, no?
    - TomMarius 8y ago
      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.
      - jackpeterfletch 8y ago
        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.
        TomMarius 8y ago
        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.
    - kodablah 8y ago
      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.
vvanders 8y ago
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 https://github.com/vvanders/wasm_lua
crooked-v 8y ago
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.
- nayuki 8y ago
  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.)
  - infogulch 8y ago
    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.
jayd16 8y ago
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.
white-flame 8y ago
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.
- Jasper_ 8y ago
  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 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.
  - shawn 8y ago
    Thanks for this comment! Very informative, and not something I would have found otherwise.
  - white-flame 8y ago
    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.
l1ambda 8y ago
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 https://github.com/WebAssembly/design/issues/960
- paulhodge 8y ago
  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.
aurelian15 8y ago
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/b557f69d00dcadfefef8594bd45bea69ca4b374a/linprog2d.in.js#L128 https://github.com/astoeckel/linprog2d/blob/b557f69d00dcadfe...
ummonk 8y ago
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.
pjmlp 8y ago
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.
- nojvek 8y ago
  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
  - pjmlp 8y ago
    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.
stewbrew 8y ago
"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.
CyberDildonics 8y ago
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.
darth_mastah 8y ago
> 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.

by krylon 8y ago

TomMarius 8y ago

You are correct, but this time, all industry leaders cooperate instead of competing: https://webassembly.org/ 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.

jayd16 8y ago
>(more "close to the metal" let's say) I don't think that's really fair to say at all.
- conradev 8y ago
  I would say that JVM bytecode is significantly higher level than WebAssembly, no?
  - TomMarius 8y ago
    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.
    - jackpeterfletch 8y ago
      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.
      - TomMarius 8y ago
        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.
  - kodablah 8y ago
    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.

vvanders 8y ago

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 https://github.com/vvanders/wasm_lua

crooked-v 8y ago

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.

nayuki 8y ago
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.)
- infogulch 8y ago
  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.

jayd16 8y ago

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.

white-flame 8y ago

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.

Jasper_ 8y ago
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 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.
- shawn 8y ago
  Thanks for this comment! Very informative, and not something I would have found otherwise.
- white-flame 8y ago
  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.

l1ambda 8y ago

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 https://github.com/WebAssembly/design/issues/960

paulhodge 8y ago
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.

aurelian15 8y ago

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/b557f69d00dcadfefef8594bd45bea69ca4b374a/linprog2d.in.js#L128 https://github.com/astoeckel/linprog2d/blob/b557f69d00dcadfe...

ummonk 8y ago

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.

pjmlp 8y ago

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.

nojvek 8y ago
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
- pjmlp 8y ago
  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.

stewbrew 8y ago

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

CyberDildonics 8y ago

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.

darth_mastah 8y ago

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