4 ms·

I disagree wit this. WASM does not run on the same VM as javascript, or rather, that V8 happens to provide the facility for both, does not mean that much. They

I disagree wit this. WASM does not run on the same VM as javascript, or rather, that V8 happens to provide the facility for both, does not mean that much. They are effectively separate things. Now, if you mean to say there's some degree of interop via a chunk of memory between the two, then fine, but that's not particularly an advantage. WASM is a bit different between browsers, it's not 'stable'. That said, Applet/JVM are 'nowhere' these days and would require specific installation. WASM is not 'faster to start' and it's not even 'fast' <-- this, and lack of clean interop is the worst thing about WASM. It's slow! If you combined the fact you have to go across an ugly 'bridge' between JS and WASM to do almost anything, it's probably not worth it for performance gains, and certainly comes with major dev. cost. 'Targeting more languages'? Really? Java, Swift, Python, Go - not really. You can target C++/C and Rust but only in very specific ways. So the advantage for WASM would be 1) security for user, but in reality v8/JS is already secure 2) performance, but in most cases it's not true 3) 'hide your code' yes, this is nice for some algs. and 4) port your C++ algs to the browser like Photoshop/Autocad. So far the reality is that it just doesn't fully add up. Maybe some day.

colordrops 5y ago
I hate to be so blunt, but almost everything you said is partially or completely incorrect. > WASM does not run on the same VM as javascript Except it does in both Chrome and Firefox, which are the vast majority of VMs out there in this space. > it's not 'stable' Once again, completely untrue. Because it runs on the same VM, it's as stable as JavaScript, which is extremely stable at this point. > WASM is not 'faster to start' and it's not even 'fast' It's effectively instantaneous simply because it's using the same engine as JavaScript, which is already loaded. I'm not talking about particular app startup up time, as that is not an aspect of the engine. I'm also not talking about interop performance, as that is unrelated. > Targeting more languages'? Really? ... not really Once again very wrong. Because LLVM targets wasm, you've got many many languages that are supported. Some examples: C/C++, C#/. NET, Rust, Java, Python, Elixir, Go
- jollybean 5y ago
  Oi. No. To say that WASM and JS run in the same VM is utterly misleading the the point of being wrong. They are not 'The Same VM'. They are 'Different VMs'. That in the case of Chrome and Firefox they happen to executed 'Side By Side' is relevant, but they are not the same vm. "Because it runs on the same VM, it's as stable as JavaScript, which is extremely stable at this point" This is a 'double down' on the fallacy that 'They are the same VM'. "It's effectively instantaneous simply because it's using the same engine as JavaScript, which is already loaded." First, so you're not going to count the startup time of the 'Engine' in the 'startup time'? But somehow that 'startup time' would be counted for example in JVM startup? That wouldn't be a useful comparison, wouldn't it? If you make a WASM-based app, you're going to have to throw in 'net startup time'. Second, aside form the issue of 'Engine' startup time, you have to consider how quickly the code gets going. It is not 'instantly', nothing is instant in a VM, notably WASM has to 'compile' - not unlike Java bytecode. Java, JS and WASM all have different profiles here. JS is 'very fast' to start, because that's why it's optimized. Java is slower to start but after about 1000 iteratons of a block of code, 'runtime profiling' makes it fast. Often faster than humans could code in C++. WASM is slow to compile, and currently has little in the way of optimization. Slow to start, slow to compute. "Because LLVM targets wasm, you've got many many languages that are supported." I'm guessing you're not a developer, and have never used WASM? You do realize you can run JS in Java? Or Java in JS? Or Rust on Java? But that would mostly be stupid and pointless in any real world environment, which is why nobody does it? Which is why nobody runs Java, C#, Python, Elixir in WASM for anything other than a mockup experiment. So no, my points are all valid. Today, WASM is the domain of Emscripten and maybe some Rust experiments, and that's that. It's slow, cumbersome, nobody is really invested in it. Maybe someday, but it's not on the horizon just yet.
  - colordrops 5y ago
    You are going to have to provide evidence of this. Everything I've heard, every presentation I've seen, everything I'm finding online is that JS and WASM share the same VM implementation on major browsers. Both our arguments hinge on whether this is true or not.

colordrops 5y ago

I hate to be so blunt, but almost everything you said is partially or completely incorrect. > WASM does not run on the same VM as javascript Except it does in both Chrome and Firefox, which are the vast majority of VMs out there in this space. > it's not 'stable' Once again, completely untrue. Because it runs on the same VM, it's as stable as JavaScript, which is extremely stable at this point. > WASM is not 'faster to start' and it's not even 'fast' It's effectively instantaneous simply because it's using the same engine as JavaScript, which is already loaded. I'm not talking about particular app startup up time, as that is not an aspect of the engine. I'm also not talking about interop performance, as that is unrelated. > Targeting more languages'? Really? ... not really Once again very wrong. Because LLVM targets wasm, you've got many many languages that are supported. Some examples: C/C++, C#/. NET, Rust, Java, Python, Elixir, Go

jollybean 5y ago
Oi. No. To say that WASM and JS run in the same VM is utterly misleading the the point of being wrong. They are not 'The Same VM'. They are 'Different VMs'. That in the case of Chrome and Firefox they happen to executed 'Side By Side' is relevant, but they are not the same vm. "Because it runs on the same VM, it's as stable as JavaScript, which is extremely stable at this point" This is a 'double down' on the fallacy that 'They are the same VM'. "It's effectively instantaneous simply because it's using the same engine as JavaScript, which is already loaded." First, so you're not going to count the startup time of the 'Engine' in the 'startup time'? But somehow that 'startup time' would be counted for example in JVM startup? That wouldn't be a useful comparison, wouldn't it? If you make a WASM-based app, you're going to have to throw in 'net startup time'. Second, aside form the issue of 'Engine' startup time, you have to consider how quickly the code gets going. It is not 'instantly', nothing is instant in a VM, notably WASM has to 'compile' - not unlike Java bytecode. Java, JS and WASM all have different profiles here. JS is 'very fast' to start, because that's why it's optimized. Java is slower to start but after about 1000 iteratons of a block of code, 'runtime profiling' makes it fast. Often faster than humans could code in C++. WASM is slow to compile, and currently has little in the way of optimization. Slow to start, slow to compute. "Because LLVM targets wasm, you've got many many languages that are supported." I'm guessing you're not a developer, and have never used WASM? You do realize you can run JS in Java? Or Java in JS? Or Rust on Java? But that would mostly be stupid and pointless in any real world environment, which is why nobody does it? Which is why nobody runs Java, C#, Python, Elixir in WASM for anything other than a mockup experiment. So no, my points are all valid. Today, WASM is the domain of Emscripten and maybe some Rust experiments, and that's that. It's slow, cumbersome, nobody is really invested in it. Maybe someday, but it's not on the horizon just yet.
- colordrops 5y ago
  You are going to have to provide evidence of this. Everything I've heard, every presentation I've seen, everything I'm finding online is that JS and WASM share the same VM implementation on major browsers. Both our arguments hinge on whether this is true or not.