Also, brand new external WASM VMs will be created (as in the OP link), and possibly used in future (or current but new versions?) browsers, again allowing for brand new security holes.

So, I'm not very convinced by this argument as of now.

I don't even understand what this is supposed to mean. Do you mean that a hole in the spec means that a sec vuln would occur in every implementation? Or that 5 implementations means 5 code bases to review?

Either way, it seems like a sentence that is meant to carry weight but is ultimately nearly completely meaningless. N different desktop apps on my computer have N chances for sec vulns. I don't see what that statement is supposed to mean regarding WebAssembly.

So it doesn't share code with a JS implementation in this case.

This project fits in the latter category. It does not claim that downloaded binaries are protected by a sandbox, and the only security claim it makes is the following weak one: “The generated code should be unable to access any memory outside of the addresses allocated to it”.

Unfortunately, the web became the only app platform that was perceived as being politically neutral, and so there was huge pressure to add features to it. These features all hugely increased the complexity of HTML renderers, and with complexity came bugs.

Could you build a smaller, simpler, safer web? Sure. It's called HTML4.

The modern web platform's bloat and what you can achieve with it always reminds me of 1990s demo scene mags on floppy disks and their mag engines. I think most of the problems stem from adding more stuff to HTML rather than taking what we build today building the smallest possible DSL and its engine around it. At some point we have to do a cut like that or we'll have browsers that'll have to support many, many HTML profiles and become monstrosities.

As wasm defines a VM, the browser could become useless.

  in my mind, as it is aimed at replacing the sprawling forests of javascript
  many pages are powered by, wasm pretty clearly addresses your three
  points. with wasm web applications delivered to browsers can be written in
  c++, rust, haskell, whatever, and compiled and linked and optimized and
  profiled and reoptimized on developer machines before deployment to end
  users. the result of this is that performant applications won't require as
  much (or any) runtime optimization like javascript engines necessarily do now:
  
  - arbitrarily dynamic code needn't be jitted and traced and rejitted to raw
    machine code at runtime
  - object structure needn't be inferred and shared and monitored and reshaped
  - primitive types don't have to be inferred and guarded
  - functions needn't be inlined and guarded because they are all dynamically
    bound
  - objects needn't be tracked and freed and moved around
  - javascript is weird and irregular. half a point here but just look at the
    equality table.
  
  you can say that 'well formed' javascript eases the pain on these poor beasts
  but they still have to strive to support as much of the common language as
  they can, no matter how awful, because it's their job. wasm has to do exactly
  none of this:
  
  - jitting can occur once, at load, statically like the CLR not dynamically
    like HotSpot or luajit as inlining happened on some jenkins box somewhere.
  - there are no objects, there are four types and they're all 4 or 8 byte
    primitives and if you need a gc you baked it into your binary. no vm-level
    object or allocation headers, no gc-related finalizer bugs.
  - desugared there's about 20 instructions (expressions). implement those and
    you've implemented webassembly. standard lib? that was compiled into the
    binary*.
  
  because there's so much less to its job it will be safer, smaller, and more
  widely consistent than javascript. it's still young and definitely not without
  its warts but these three points are home runs.
  
  * ..ish, but it's definitely more spartan:
      https://webassembly.github.io/demo/AngryBots/Release/AngryBots.js
    ... that'll buff out :p

  edit: wow i suck at HN formatting

Ie, is Nodejs to Javascript as WAVM is to WASM?

WAVM is more like V8, but for WebAssembly only instead of both JavaScript and WebAssembly. The purpose is to serve as a simple VM for my programming language that compiles to WebAssembly.

If it would have GC, other languages would have to use the supplied GC.

If it wouldn't have GC, other languages could simply implement their own GC.

WebAssembly definitely benefits from being able to avoid the JavaScript garbage collector.

I'm working on a garbage collected language that will use WebAssembly/WAVM as that backend. It's possible as-is, but may require some non-standard extensions to get good performance (e.g. to find GC roots on the stack). I'll certainly contribute anything I do there for standardization, but I suspect the WebAssembly committee will beat me to it.

There might not be that big of a performance penalty once WebAssembly gets SIMD, shared memory threads and 64bit ints though.

when that would be so easy, maybe. But especially on top of the browser restrictions that will be even harder.

Yes I think that's the idea.

I don't understand why people moan about GC in WebAsm. WebAsm is a compiler target for lower level languages, not the JVM.