5 ms·

> We already have a bunch of great runtimes, compilers, and opcodes. I'm confused. Are you suggesting we, for example, use the JVM for this instead? WASM is be

by Ajedi32 10y ago

> We already have a bunch of great runtimes, compilers, and opcodes. I'm confused. Are you suggesting we, for example, use the JVM for this instead? WASM is being designed specifically with the web in mind, and has a lot of design goals which just weren't a concern for other runtimes. See: http://webassembly.org/docs/high-level-goals/ http://webassembly.org/docs/high-level-goals/

exabrial 10y ago
Well not exactly, but I feel like the JVM, LLVM, parrot, CLR, or any one of those that have well defined opcodes could be leveraged instead of producing something entirely new. There's quite a bit of investment in those projects... Does that make more sense what I was trying to say?
- Ajedi32 10y ago
  They actually have that question in their FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md#why-not-just-use-llvm-bitcode-as-a-binary-format https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
  - exabrial 10y ago
    I guess that particular case makes sense. Straight LLVM IR would probably be a security risk anyway unless they built a fairly solid verifier.
- n00b101 10y ago
  The reason for not using LLVM bitcode or ASM.js is already covered in detail here https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md I am unsure how JVM or CLR are relevant. WebAssembly is not a virtual machine byte code (and neither is LLVM, despite the name). As the name "WebAssembly" suggests, it is like an assembly language level target for "the web" (more precisely, for JavaScript interpreters found in web browsers). It is true that there is a lot of unfortunate duplication of effort and fracturing of technology happening here, due to historical legacy issues with web browsers. JVM and CLR are indeed highly mature and presumably secure VMs today. If we were to wave a magic wand and rewrite the history of the web browsers, perhaps it would be much better if JavaScript never existed and browsers used an off-the-shelf, standardized VM like JVM or CLR and we wrote web apps in C# or Java (or, at our discretion, F#, etc). This wouldn't solve the problem that WebAssembly is solving (i.e compiling native code, eg C++, for execution in the browser), but then maybe we wouldn't have needed that today if everyone (native and web) had standardized on a single VM target. But that's just not how things turned out, browsers created their own parallel technology stack from scratch so things like WebAssembly need to be created from scratch to work within the constraints that we are stuck with.
  - zigzigzag 10y ago
    I wrote more on this above, so I won't repeat myself in this comment, but yes WebAssembly is a "virtual machine byte code". It is literally a bytecode language that doesn't target physical machines. It bears no resemblence to x86 or ARM so it has to be JIT compiled or interpreted. Saying it doesn't target a VM because it targets "the web" is meaningless.
    - n00b101 10y ago
      Fair enough. You are correct, WebAssembly is a bytecode for the underlying machinery of current ECMAScript/JavaScript engines. I think you raise a very good question, why did the WebAssembly committee decide to implement their own stack machine bytecode instead of re-using an existing bytecode like JVM or CLI (which, interestingly, is an ECMA standard)? It's troubling. The closest explanation I could find is: "Why not a fully-general stack machine? The WebAssembly stack machine is restricted to structured control flow and structured use of the stack. This greatly simplifies one-pass verification, avoiding a fixpoint computation like that of other stack machines such as the Java Virtual Machine (prior to stack maps). This also simplifies compilation and manipulation of WebAssembly code by other tools. Further generalization of the WebAssembly stack machine is planned post-MVP, such as the addition of multiple return values from control flow constructs and function calls." [1] [1] http://webassembly.org/docs/rationale/ http://webassembly.org/docs/rationale/
    - n00b101 10y ago
      I found the relevant discussion on this: https://github.com/WebAssembly/design/issues/960 https://github.com/WebAssembly/design/issues/960
zigzigzag 10y ago
And Java was designed with the web in mind too. You could access the DOM from applets back in the day, it's not fundamentally so different. I feel like "designed for the web" doesn't really mean much when you zoom out. When I look at that bytecode set, it is less strongly typed and has more opcodes than JVM bytecode, but otherwise is rather comparable. It isn't based on any actually existing hardware instruction set so it must be interpreted or JIT compiled. It has explicit opcodes for things like popcnt and clz instead of relying on compiler intrinsics, but that's not anything that matters when you need a translation layer anyway. It has bytecodes that do static and virtual method dispatch, just like JVM bytecode. The main difference seems to be that it doesn't provide GC or locks or other things that higher level languages need. As far as I can tell, the browser community insists on constantly reinventing the wheel because of a kind of NIH syndrome often justified by security, but how robust is that justification? You can't have regular sockets, you need "WebSockets", although the web has permissioned APIs in many other areas. You can't use any existing VM and bytecode set like the JVM because they're "insecure", although both Firefox and Chrome are constantly patching sandbox escapes too: it just comes with the space. However they're "web" and thus excused, Microsoft/Java aren't "web" and thus guilty. Ditto for Flash. You can't have threads like C#/Java have because Javascript engines happen not to be thread safe, instead you get "Web Workers" which are really just the Visual Basic 6 concurrency model reborn without the benefit of DCOM to assist with the messaging, but now it's "Web" it's hip and cool. Maybe I'm just the grumpy old man yelling at the clouds, but browser tech is stuck in a hamster wheel where they insist on reinventing things that were already working fine elsewhere in the industry.

by Ajedi32 10y ago

exabrial 10y ago

Well not exactly, but I feel like the JVM, LLVM, parrot, CLR, or any one of those that have well defined opcodes could be leveraged instead of producing something entirely new. There's quite a bit of investment in those projects... Does that make more sense what I was trying to say?

Ajedi32 10y ago
They actually have that question in their FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md#why-not-just-use-llvm-bitcode-as-a-binary-format https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
- exabrial 10y ago
  I guess that particular case makes sense. Straight LLVM IR would probably be a security risk anyway unless they built a fairly solid verifier.
n00b101 10y ago
The reason for not using LLVM bitcode or ASM.js is already covered in detail here https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md I am unsure how JVM or CLR are relevant. WebAssembly is not a virtual machine byte code (and neither is LLVM, despite the name). As the name "WebAssembly" suggests, it is like an assembly language level target for "the web" (more precisely, for JavaScript interpreters found in web browsers). It is true that there is a lot of unfortunate duplication of effort and fracturing of technology happening here, due to historical legacy issues with web browsers. JVM and CLR are indeed highly mature and presumably secure VMs today. If we were to wave a magic wand and rewrite the history of the web browsers, perhaps it would be much better if JavaScript never existed and browsers used an off-the-shelf, standardized VM like JVM or CLR and we wrote web apps in C# or Java (or, at our discretion, F#, etc). This wouldn't solve the problem that WebAssembly is solving (i.e compiling native code, eg C++, for execution in the browser), but then maybe we wouldn't have needed that today if everyone (native and web) had standardized on a single VM target. But that's just not how things turned out, browsers created their own parallel technology stack from scratch so things like WebAssembly need to be created from scratch to work within the constraints that we are stuck with.
- zigzigzag 10y ago
  I wrote more on this above, so I won't repeat myself in this comment, but yes WebAssembly is a "virtual machine byte code". It is literally a bytecode language that doesn't target physical machines. It bears no resemblence to x86 or ARM so it has to be JIT compiled or interpreted. Saying it doesn't target a VM because it targets "the web" is meaningless.
  - n00b101 10y ago
    Fair enough. You are correct, WebAssembly is a bytecode for the underlying machinery of current ECMAScript/JavaScript engines. I think you raise a very good question, why did the WebAssembly committee decide to implement their own stack machine bytecode instead of re-using an existing bytecode like JVM or CLI (which, interestingly, is an ECMA standard)? It's troubling. The closest explanation I could find is: "Why not a fully-general stack machine? The WebAssembly stack machine is restricted to structured control flow and structured use of the stack. This greatly simplifies one-pass verification, avoiding a fixpoint computation like that of other stack machines such as the Java Virtual Machine (prior to stack maps). This also simplifies compilation and manipulation of WebAssembly code by other tools. Further generalization of the WebAssembly stack machine is planned post-MVP, such as the addition of multiple return values from control flow constructs and function calls." [1] [1] http://webassembly.org/docs/rationale/ http://webassembly.org/docs/rationale/
  - n00b101 10y ago
    I found the relevant discussion on this: https://github.com/WebAssembly/design/issues/960 https://github.com/WebAssembly/design/issues/960

zigzigzag 10y ago

And Java was designed with the web in mind too. You could access the DOM from applets back in the day, it's not fundamentally so different. I feel like "designed for the web" doesn't really mean much when you zoom out. When I look at that bytecode set, it is less strongly typed and has more opcodes than JVM bytecode, but otherwise is rather comparable. It isn't based on any actually existing hardware instruction set so it must be interpreted or JIT compiled. It has explicit opcodes for things like popcnt and clz instead of relying on compiler intrinsics, but that's not anything that matters when you need a translation layer anyway. It has bytecodes that do static and virtual method dispatch, just like JVM bytecode. The main difference seems to be that it doesn't provide GC or locks or other things that higher level languages need. As far as I can tell, the browser community insists on constantly reinventing the wheel because of a kind of NIH syndrome often justified by security, but how robust is that justification? You can't have regular sockets, you need "WebSockets", although the web has permissioned APIs in many other areas. You can't use any existing VM and bytecode set like the JVM because they're "insecure", although both Firefox and Chrome are constantly patching sandbox escapes too: it just comes with the space. However they're "web" and thus excused, Microsoft/Java aren't "web" and thus guilty. Ditto for Flash. You can't have threads like C#/Java have because Javascript engines happen not to be thread safe, instead you get "Web Workers" which are really just the Visual Basic 6 concurrency model reborn without the benefit of DCOM to assist with the messaging, but now it's "Web" it's hip and cool. Maybe I'm just the grumpy old man yelling at the clouds, but browser tech is stuck in a hamster wheel where they insist on reinventing things that were already working fine elsewhere in the industry.