3 ms·

And can someone ELI5 why WebAssembly is useful, given that there are already a myriad of other virtual machines out there (JVM, CLR, BEAM, etc)? And why could/

And can someone ELI5 why WebAssembly is useful, given that there are already a myriad of other virtual machines out there (JVM, CLR, BEAM, etc)? And why could/did those other virtual machines not evolve to fulfill the need that WebAssembly fulfills? Why is a new machine language and new virtual machine necessary?

IshKebab 4y ago
Webassembly can be targeted by C/C++ and Rust. It's also designed with security in mind. The JVM is not a reliable sandbox.
- sanxiyn 4y ago
  JVM also can be targeted by C/C++ and Rust. In fact NestedVM was published in 2004... I concede WebAssembly does sandboxing better.
  - IshKebab 4y ago
    There's also the fact that the JVM is huge (~160MB download) but a WASM runtime is like 4MB.
indymike 4y ago
>And why could/did those other virtual machines not evolve to fulfill the need that WebAssembly fulfills? All three were designed primarily as bytecode interpeters that would run as a layer between the OS and application, and were primarily designed to run stand-alone (i.e. desktop/server apps). Java was originally included in most web browsers, but the applet model just didn't get it done for users - and most Java software moved either be web applications (i.e. serving HTML) or desktop or mobile applications. > Why is a new machine language and new virtual machine necessary? WASM was designed to be embedable (and secure), streamable and is now ubiquitous as it is supported by all three major browsers, plus Node (and Deno) and many desktop web-app platforms (e.g. Electron). The embedable part is what makes it really different than JVM, CLR and BEAM - for example, you can include a WASM runtime in your application and call WASM code from a C or Rust app just like the browser does.
- pjmlp 4y ago
  Better educate yourself on the CLR, not only was it designed for multiple languages, including C++, it doesn't support interpeters, only AOT and JIT compilation.
  - indymike 4y ago
    Never made that claim. You are an expert on both CLR and JVM... what is your take on WASM?
    - pjmlp 4y ago
      It should stay in the browser, and is the political outcome of Mozilla not adopting PNaCL, which is kind of ironinc given how they are now struggling with 3% market share. Had it been today, Google would have been able to push PNaCL no matter what. > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language. -- February 2002 issue of MSDN Magazine https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net https://learn.microsoft.com/en-us/archive/msdn-magazine/2002... As for the JVM, it is kind of ironic as well, that after bashing Java Application Servers, there are startups trying to replicate them using a mix of Docker containers, Kubernetes and WASM. So they aren't that bad after all.
      - indymike 4y ago
        It's kind of entertaining watching the same set of ideas be tried in different ways over the years.
andrewaylett 4y ago
In a real sense, WASM isn't a new VM. It's an evolution of Javascript, via asm.js, so it builds on the sandboxing that browsers need for JS. As part of that, it really doesn't do very much. Other more general purpose VMs first let you do things. This has implications for running untrusted code: the JVM has never _quite_ managed to lock things down, and has a model where we restrict code that would otherwise have access (via reflection) to a lot of things we don't want it to have access to. WASM starts with a bounded set of "RAM" and the ability to define code that runs on a "CPU". There's no mechanism for the CPU to access anything outside of the data it's been explicitly allocated. That makes it more difficult to actually do anything, but also more difficult for malicious code to do anything it shouldn't. With much stricter invariants comes the ability to statically validate the invariants, too. Which is where projects like Mozilla's use of WASM as an intermediate format that's then converted to C are really interesting: correctly written C will maintain these invariants too, but we can't validate them directly. We can validate the invariants in WASM then maintain them by construction as we convert to C and onwards to native code.
mike_hearn 4y ago
The main thing is that browser makers can implement it on top of their existing JS engines at relatively low cost, and the language model is basically just C so there's no difficult consensus building. In other words it's expedient for the browser guys, given that Mozilla killed all prior attempts to do things like NaCL, there was also an earlier initiative to teach V8 how to run JVM bytecode that got killed off by the same problem. Mozilla just systematically killed off any attempt to non-JS stuff. WASM sort of snuck in via the backdoor using hacks like Emscripten and asm.js and Firefox was losing market share, so WASM is what we ended up with. Outside the browser as the other comments say it's about sandboxing primarily, and the feeling that it's not too dependent on a single vendor. Of course that means not much useful code runs inside WASM. The hard bit about sandboxing is not actually doing it, so much as allowing a usefully flexible set of permissions and features for sandboxed code. Interestingly, Graal is also developing a sandbox. And with native-image you can compile the language implementations down to native code. So you could soon (even today actually but it's not really advertised) load a sandboxing JS or Python or Ruby or indeed WASM implementation from a shared library using a simple C API. Again though the hard part is actually that "real" code tends to have extensive OS dependencies. The JS ecosystem finds wide usage partly because so many modules are written for the browser which allows very little, whereas in the Python/Java/etc ecosystems modules frequently will assume things like filesystem access.

IshKebab 4y ago

Webassembly can be targeted by C/C++ and Rust. It's also designed with security in mind. The JVM is not a reliable sandbox.

sanxiyn 4y ago
JVM also can be targeted by C/C++ and Rust. In fact NestedVM was published in 2004... I concede WebAssembly does sandboxing better.
- IshKebab 4y ago
  There's also the fact that the JVM is huge (~160MB download) but a WASM runtime is like 4MB.

indymike 4y ago

>And why could/did those other virtual machines not evolve to fulfill the need that WebAssembly fulfills? All three were designed primarily as bytecode interpeters that would run as a layer between the OS and application, and were primarily designed to run stand-alone (i.e. desktop/server apps). Java was originally included in most web browsers, but the applet model just didn't get it done for users - and most Java software moved either be web applications (i.e. serving HTML) or desktop or mobile applications. > Why is a new machine language and new virtual machine necessary? WASM was designed to be embedable (and secure), streamable and is now ubiquitous as it is supported by all three major browsers, plus Node (and Deno) and many desktop web-app platforms (e.g. Electron). The embedable part is what makes it really different than JVM, CLR and BEAM - for example, you can include a WASM runtime in your application and call WASM code from a C or Rust app just like the browser does.

pjmlp 4y ago
Better educate yourself on the CLR, not only was it designed for multiple languages, including C++, it doesn't support interpeters, only AOT and JIT compilation.
- indymike 4y ago
  Never made that claim. You are an expert on both CLR and JVM... what is your take on WASM?
  - pjmlp 4y ago
    It should stay in the browser, and is the political outcome of Mozilla not adopting PNaCL, which is kind of ironinc given how they are now struggling with 3% market share. Had it been today, Google would have been able to push PNaCL no matter what. > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language. -- February 2002 issue of MSDN Magazine https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/february/editor-s-note-welcome-visual-studio-net https://learn.microsoft.com/en-us/archive/msdn-magazine/2002... As for the JVM, it is kind of ironic as well, that after bashing Java Application Servers, there are startups trying to replicate them using a mix of Docker containers, Kubernetes and WASM. So they aren't that bad after all.
    - indymike 4y ago
      It's kind of entertaining watching the same set of ideas be tried in different ways over the years.

andrewaylett 4y ago

In a real sense, WASM isn't a new VM. It's an evolution of Javascript, via asm.js, so it builds on the sandboxing that browsers need for JS. As part of that, it really doesn't do very much. Other more general purpose VMs first let you do things. This has implications for running untrusted code: the JVM has never _quite_ managed to lock things down, and has a model where we restrict code that would otherwise have access (via reflection) to a lot of things we don't want it to have access to. WASM starts with a bounded set of "RAM" and the ability to define code that runs on a "CPU". There's no mechanism for the CPU to access anything outside of the data it's been explicitly allocated. That makes it more difficult to actually do anything, but also more difficult for malicious code to do anything it shouldn't. With much stricter invariants comes the ability to statically validate the invariants, too. Which is where projects like Mozilla's use of WASM as an intermediate format that's then converted to C are really interesting: correctly written C will maintain these invariants too, but we can't validate them directly. We can validate the invariants in WASM then maintain them by construction as we convert to C and onwards to native code.

mike_hearn 4y ago

The main thing is that browser makers can implement it on top of their existing JS engines at relatively low cost, and the language model is basically just C so there's no difficult consensus building. In other words it's expedient for the browser guys, given that Mozilla killed all prior attempts to do things like NaCL, there was also an earlier initiative to teach V8 how to run JVM bytecode that got killed off by the same problem. Mozilla just systematically killed off any attempt to non-JS stuff. WASM sort of snuck in via the backdoor using hacks like Emscripten and asm.js and Firefox was losing market share, so WASM is what we ended up with. Outside the browser as the other comments say it's about sandboxing primarily, and the feeling that it's not too dependent on a single vendor. Of course that means not much useful code runs inside WASM. The hard bit about sandboxing is not actually doing it, so much as allowing a usefully flexible set of permissions and features for sandboxed code. Interestingly, Graal is also developing a sandbox. And with native-image you can compile the language implementations down to native code. So you could soon (even today actually but it's not really advertised) load a sandboxing JS or Python or Ruby or indeed WASM implementation from a shared library using a simple C API. Again though the hard part is actually that "real" code tends to have extensive OS dependencies. The JS ecosystem finds wide usage partly because so many modules are written for the browser which allows very little, whereas in the Python/Java/etc ecosystems modules frequently will assume things like filesystem access.