Note that WebAssembly is an MVP right now. It's getting threads, SIMD, native DOM interaction, GC, which would allow many languages to compile to it and run efficiently.
It now links to here: https://github.com/WebAssembly/design/issues/1079
The person maintaining that mirror went back to grad school, I'll see who maintains it now. Apologies for the 404.
I disagree. Flash could draw things without interacting with DOM thorough JS. Also Flash had sophisticated IDE. WebAssembly is just asm.js+ with a strong aim to compile C/C++ for the web, so you don't need to rewrite anything.
I'm not sure what you mean about the IDE? Webassembly won't restrict what source language you use so you'll be able to use any IDE that supports your chosen language. And that would include Flash and its tools if someone writes a compiler.
And not only. From the paper: "WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web". It could have some use in the embedded space, for securely embedding code. Java is sometimes used to sandbox code, if the WA compiler is slim enough it could be an alternative. A big difference is of course the libraries, which are not in the WA scope. But for some embedded use cases this is not a blocker: the API is there at the C level, one just need to expose it to the WA runtime (which could be automated, see SWIG and the like). A secure format, with some strong backers and high performance open source implementations has a lot of potential. I'm very curious about the footprint of the loader/compiler/runtime: it should be ok for most Linux embedded systems, but how low-end could it go as a secure ISA agnostic code distribution system?
For your second point, JavaScript is also sandboxed. On principle, there is no reason that in time the API offered to JS today won't become available to the WA runtime in the future --- although I've no idea if there's any actual work along those lines, I don't follow web front-end tech too closely.
There are all kinds of abstractions interact with the language outside the sandbox though: DOM, XMLHttpRequest, WebSocket, Cookies, location object, localStorage, IndexedDB, and on and on....
To my knowledge WASM does not have such a variety of APIs to expose access. The reason for this difference is that the security emphasis for WASM is instruction integrity while with JavaScript the emphasis is integrity of IO.
WASM runs closer to the metal and so if any of the security CIA (confidentiality, integrity, availability) are broken everything that relies upon it, executes from it, or works with it could be exposed through memory. In this case it is the execution state that is important. JavaScript is not a bytecode format and so it can execute in a VM without the VM ever being exposed. All that matters for JavaScript is that it receives standard input and returns standard output.
See the design documents: https://github.com/WebAssembly/design/blob/master/Portabilit...
But yeah, interop is something that you can't just hand-wave away. It needs to be done carefully and with the right semantics and performance. That said I think we well get there and for a certain limited use cases it's already there.
As long as you don't make 1000's of calls per frame it runs pretty well.
It already is. Lua has already been ported to WebAssembly, people are writing apps in C/C++ with SDL, I've seen MVPs of .Net, and once WASM gets native garbage collection, the floodgates are going to open. The sandbox only makes it more attractive.
Yes, you won't be able to use the filesystem and other std stuff, but you want to do browser stuff in the browser, like creating websockets and coloring your dom nodes in various colors
Is it? How do we know? The attack surface in browsers is huge.
1. WebAssembly has almost no APIs to the platforms whereas Flash had a bunch (i.e. it's "as safe as JavaScript, because it can only call JavaScript"). 2. The code is all new, as opposed to what I hear is a hard-to-maintain older codebase which wasn't designed with security in mind. 3. It's very static in that memory accesses are pretty easy to bounds check for the compiler.
Implementation-wise there's plenty of interesting things that can be done to tighten security of WebAssembly.
If anyone had actually cared about security on the web we wouldn't be where we are now.
And we already have a bluetooth stack for the web, USB drivers in JS, etc.
To the point that they redefined the URL spec and then complained that cURL didn't fulfill it.
Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform, which WebAssembly absolutely isn't. Everything running from WASM is in an isolated sandbox. For obvious security reasons this isn't likely to change.