3 ms·

Wrong. WASM is just a bytecode format. There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up. A lot of

Wrong. WASM is just a bytecode format. There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up. A lot of people have imagined that WASM (or eBPF, but that's another can of worms) somehow has some magic sauce that enables it to guarantee correctness or process isolation. The truth is your sandbox is only as good as the weakest link in (1) Your sandbox runtime (2) Your RPC/API call protocol that you're using to control the outside world from within your sandbox, which everyone has to build from scratch.

rdtsc 3y ago
Sure it is bytecode but runs in the browser. That's the magic bit. Clients don't have to install .net, java, etc. And because it can be a target for some compiled languages, we can play cool games built in C and such in the browser. It also has this property that it makes for very cool demos. It may be useful or not in larger production environments, but it's hard to deny that it looks cool when being showed off. The danger is when someone in charge becomes enamored by it and now the whole 20 person team is spending the next two years rewriting a production system in it.
- phendrenad2 3y ago
  Most of the exuberance over WASM (including in this article) is over the potential for running it outside of the browser, such as (apparently) in IoT devices (this article) or as a Docker replacement[1]. For the record, I think WASM is a good idea in the browser (but is still of limited usability until they add direct DOM manipulation, and I feel like someone is intentionally blocking that) [1] - https://news.ycombinator.com/item?id=34078737 https://news.ycombinator.com/item?id=34078737
- gwervc 3y ago
  > Sure it is bytecode but runs in the browser. About half if not more posts are about WASI (WebAssembly outside the browser). There really isn't anything new to justifying the level of hype; bytecode or code running in the browser already have been done and eventually removed decades ago (respectively Java applets and ActiveX).
  - joquarky 3y ago
    Also, Java applets and ActiveX objects were notoriously lacking in accessibility. I see the same happening with WASM-based web apps if they don't find an elegant way to directly utilize the DOM.
    - genman 3y ago
      That is my main concern and I am following this WASM story with growing caution.
    - PaulDavisThe1st 3y ago
      Cardinal [0] is a wasm-based web app. What on earth would the DOM have to do with a modular synthesis environment? You seem to be imagining that wasm-based web apps implies a fairly strong connection to existing HTML/CSS/JS "pages". This is not the case and is an unnecessary cognitive barrier to thinking about what wasm (in-browser) could make possible. [0] https://cardinal.kx.studio/live https://cardinal.kx.studio/live
      - filleduchaos 3y ago
        And it's lacking in accessibility, just as the person you're responding to said. > What on earth would the DOM have to do with a modular synthesis environment? The fact that unlike people's cool and dreamy bespoke UIs drawn entirely on canvas, the DOM does actually have a competently implemented accessibility services layer that apps using it get for free out of the box. Not to mention that you've never needed WASM to draw UIs entirely on canvas either. It's a silly idea with JS and a silly idea with WASM.
        PaulDavisThe1st 3y ago
        This application is written in C++. It has no accessibility features because nobody has ever figured how to do that with a virtual modular synthesis environment that is absolutely intended to be (a) extremely skeuomorphic (b) extremely visual. The same issue exists in the native world too, and isn't going to be solved by somehow connecting a DOM with the canvas.
Joker_vD 3y ago
> There's nothing new here compared to ... whatever other VM bytecode formats have been dreamed up Well, there is: it was designed to be easy for already mature V8's codebase to adopt as a low-level IR, with minimal changes (e.g. V8 keeps the JS AST more or less intact during the codegen, it doesn't lower it into 3-address code or anything like that, so WASM too has structured loops and blocks but no general "goto"). Other VMs, I believe, were developed after the bytecode design for them was done.
- pjmlp 3y ago
  Kind of ironic given PNaCL was equally designed for V8.
  - titzer 3y ago
    I worked a lot with the PNaCL team and they never told us that. Unless you have a reference I am aware of in a design doc. PNaCL was LLVM bitcode.
    - pjmlp 3y ago
      Used by V8 execution pipeline on Chrome. It isn't as if it was given other execution runtime, so it certainly wasn't designed for Firefox, IE, Safari, Opera,...
      - titzer 3y ago
        No, PNaCl used LLVM initially and was working on a faster compiler internally (SubZero) before we refocused efforts on Wasm. You might be referring to the effort to port V8's compiler(s) to emit sandboxed code, but that was never merged into mainstream V8.
- sesm 3y ago
  Ok, so WASM was designed to be a more low-level interface to V8. This makes sense from a technical PoV and from promotion-driven culture at Google. But it doesn’t originate from any real-world problem, just a hammer looking for a nail.
pjmlp 3y ago
Yeah, this kind of posts selling Webassembly as if it wasn't been done before, multiple times since the 1960's is getting tiring.
zozbot234 3y ago
> There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up. WASM is far more low-level than those. It does not depend on the semantics of any existing programming language, and while it does sandbox the code it does not focus on providing mechanisms for establishing memory safety other than at the module level. The focus is almost solely on minimizing overhead compared to native code, even the GC implementation is kept as simple and efficient as possible.
- phendrenad2 3y ago
  > does not depend on the semantics of any existing programming language So? The JVM does not depend on the semantics of any existing programming language. I think more research is needed on your part.
munificent 3y ago
Not all bytecode formats are the same. Steel-reinforced concrete is "just" another building material, but what you can do with it in practice is very different from wattle and daub.
- phendrenad2 3y ago
  Not all AAA batteries are the same, either. But for all intents and purposes, quibbling over differences is trivial.
- PaulDavisThe1st 3y ago
  For most modern CPUs, "machine code" is just another bytecode. Not much of a problem with that, it would seem.

rdtsc 3y ago

Sure it is bytecode but runs in the browser. That's the magic bit. Clients don't have to install .net, java, etc. And because it can be a target for some compiled languages, we can play cool games built in C and such in the browser. It also has this property that it makes for very cool demos. It may be useful or not in larger production environments, but it's hard to deny that it looks cool when being showed off. The danger is when someone in charge becomes enamored by it and now the whole 20 person team is spending the next two years rewriting a production system in it.

phendrenad2 3y ago
Most of the exuberance over WASM (including in this article) is over the potential for running it outside of the browser, such as (apparently) in IoT devices (this article) or as a Docker replacement[1]. For the record, I think WASM is a good idea in the browser (but is still of limited usability until they add direct DOM manipulation, and I feel like someone is intentionally blocking that) [1] - https://news.ycombinator.com/item?id=34078737 https://news.ycombinator.com/item?id=34078737
gwervc 3y ago
> Sure it is bytecode but runs in the browser. About half if not more posts are about WASI (WebAssembly outside the browser). There really isn't anything new to justifying the level of hype; bytecode or code running in the browser already have been done and eventually removed decades ago (respectively Java applets and ActiveX).
- joquarky 3y ago
  Also, Java applets and ActiveX objects were notoriously lacking in accessibility. I see the same happening with WASM-based web apps if they don't find an elegant way to directly utilize the DOM.
  - genman 3y ago
    That is my main concern and I am following this WASM story with growing caution.
  - PaulDavisThe1st 3y ago
    Cardinal [0] is a wasm-based web app. What on earth would the DOM have to do with a modular synthesis environment? You seem to be imagining that wasm-based web apps implies a fairly strong connection to existing HTML/CSS/JS "pages". This is not the case and is an unnecessary cognitive barrier to thinking about what wasm (in-browser) could make possible. [0] https://cardinal.kx.studio/live https://cardinal.kx.studio/live
    - filleduchaos 3y ago
      And it's lacking in accessibility, just as the person you're responding to said. > What on earth would the DOM have to do with a modular synthesis environment? The fact that unlike people's cool and dreamy bespoke UIs drawn entirely on canvas, the DOM does actually have a competently implemented accessibility services layer that apps using it get for free out of the box. Not to mention that you've never needed WASM to draw UIs entirely on canvas either. It's a silly idea with JS and a silly idea with WASM.
      - PaulDavisThe1st 3y ago
        This application is written in C++. It has no accessibility features because nobody has ever figured how to do that with a virtual modular synthesis environment that is absolutely intended to be (a) extremely skeuomorphic (b) extremely visual. The same issue exists in the native world too, and isn't going to be solved by somehow connecting a DOM with the canvas.

Joker_vD 3y ago

> There's nothing new here compared to ... whatever other VM bytecode formats have been dreamed up Well, there is: it was designed to be easy for already mature V8's codebase to adopt as a low-level IR, with minimal changes (e.g. V8 keeps the JS AST more or less intact during the codegen, it doesn't lower it into 3-address code or anything like that, so WASM too has structured loops and blocks but no general "goto"). Other VMs, I believe, were developed after the bytecode design for them was done.

pjmlp 3y ago
Kind of ironic given PNaCL was equally designed for V8.
- titzer 3y ago
  I worked a lot with the PNaCL team and they never told us that. Unless you have a reference I am aware of in a design doc. PNaCL was LLVM bitcode.
  - pjmlp 3y ago
    Used by V8 execution pipeline on Chrome. It isn't as if it was given other execution runtime, so it certainly wasn't designed for Firefox, IE, Safari, Opera,...
    - titzer 3y ago
      No, PNaCl used LLVM initially and was working on a faster compiler internally (SubZero) before we refocused efforts on Wasm. You might be referring to the effort to port V8's compiler(s) to emit sandboxed code, but that was never merged into mainstream V8.
sesm 3y ago
Ok, so WASM was designed to be a more low-level interface to V8. This makes sense from a technical PoV and from promotion-driven culture at Google. But it doesn’t originate from any real-world problem, just a hammer looking for a nail.

pjmlp 3y ago

Yeah, this kind of posts selling Webassembly as if it wasn't been done before, multiple times since the 1960's is getting tiring.

zozbot234 3y ago

> There's nothing new here compared to JVM, Parrot, CLR, whatever other VM bytecode formats have been dreamed up. WASM is far more low-level than those. It does not depend on the semantics of any existing programming language, and while it does sandbox the code it does not focus on providing mechanisms for establishing memory safety other than at the module level. The focus is almost solely on minimizing overhead compared to native code, even the GC implementation is kept as simple and efficient as possible.

phendrenad2 3y ago
> does not depend on the semantics of any existing programming language So? The JVM does not depend on the semantics of any existing programming language. I think more research is needed on your part.

munificent 3y ago

Not all bytecode formats are the same. Steel-reinforced concrete is "just" another building material, but what you can do with it in practice is very different from wattle and daub.

phendrenad2 3y ago
Not all AAA batteries are the same, either. But for all intents and purposes, quibbling over differences is trivial.
PaulDavisThe1st 3y ago
For most modern CPUs, "machine code" is just another bytecode. Not much of a problem with that, it would seem.