14 ms·

WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the ne

WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. 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.

hdhzy 9y ago
> Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. 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.
- ChrisSD 9y ago
  There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc). 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.
  - hdhzy 9y ago
    I mean Flash had a dedicated IDE. WebAssembly can be compared to ABC (ActionScript Bytecode) not to Flash.
- drdrey 9y ago
  WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for the source language, not the target.
  - panopticon 9y ago
    That's his/her point; they were trying to point out why Flash and WebAssembly aren't analogous.. Flash was a cohesive toolchain; not a build target.
  - hdhzy 9y ago
    Exactly. So the patent can compare WebAssembly to ActionScript byte code or swf binary format not to Flash.
yaantc 9y ago
> ..., to the web 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.
- austincheney 9y ago
  > For your second point, JavaScript is also sandboxed. 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.
  - ChrisSD 9y ago
    Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc. See the design documents: https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...
markdog12 9y ago
> 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. 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. http://webassembly.org/docs/future-features/ http://webassembly.org/docs/future-features/
- austincheney 9y ago
  I did not see native DOM interaction in that document and the thing it linked to is 404.
  - jfbastien 9y ago
    Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat... It now links to here: https://github.com/WebAssembly/design/issues/1079 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.
vvanders 9y ago
Well anything that lets me run Lua in the browser[1] is cool by me ;). 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. [1] https://github.com/vvanders/wasm_lua https://github.com/vvanders/wasm_lua
- Zelizz 9y ago
  Oh man, with Lua in the browser, I'd actually start to write web stuff again. And we could get a really nice fast port of Love2D running!
  - vvanders 9y ago
    Yeah, probably wouldn't be too hard. I've got Lua things drawing to an HTML5 canvas that runs at 60 FPS on a private project. As long as you don't make 1000's of calls per frame it runs pretty well.
ams6110 9y ago
> more secure Is it? How do we know? The attack surface in browsers is huge.
- jfbastien 9y ago
  A few ways that come to mind: 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.
  - AnIdiotOnTheNet 9y ago
    And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other. If anyone had actually cared about security on the web we wouldn't be where we are now.
    - jfbastien 9y ago
      Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/
      - kuschku 9y ago
        That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG. And we already have a bluetooth stack for the web, USB drivers in JS, etc.
        9y ago
krapp 9y ago
>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. 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.
- txdv 9y ago
  Yeah, I wonder why OP thinks that the sandbox is bad. 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

hdhzy 9y ago

> Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. 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.

ChrisSD 9y ago
There are various drawing surfaces on the web that don't involve interacting with the DOM (canvas, webgl, etc). 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.
- hdhzy 9y ago
  I mean Flash had a dedicated IDE. WebAssembly can be compared to ABC (ActionScript Bytecode) not to Flash.
drdrey 9y ago
WebAssembly is a compilation target (like JVM Bytecode). You need an IDE for the source language, not the target.
- panopticon 9y ago
  That's his/her point; they were trying to point out why Flash and WebAssembly aren't analogous.. Flash was a cohesive toolchain; not a build target.
- hdhzy 9y ago
  Exactly. So the patent can compare WebAssembly to ActionScript byte code or swf binary format not to Flash.

yaantc 9y ago

> ..., to the web 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.

austincheney 9y ago
> For your second point, JavaScript is also sandboxed. 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.
- ChrisSD 9y ago
  Actually the eventual goal is to give WASM access to import "environment" apis, which in the browser means DOM, Cookies, etc. See the design documents: https://github.com/WebAssembly/design/blob/master/Portability.md#api https://github.com/WebAssembly/design/blob/master/Portabilit...

markdog12 9y ago

> 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. 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. http://webassembly.org/docs/future-features/ http://webassembly.org/docs/future-features/

austincheney 9y ago
I did not see native DOM interaction in that document and the thing it linked to is 404.
- jfbastien 9y ago
  Hmm, that website mirrors github but got stale: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat... It now links to here: https://github.com/WebAssembly/design/issues/1079 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.

vvanders 9y ago

Well anything that lets me run Lua in the browser[1] is cool by me ;). 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. [1] https://github.com/vvanders/wasm_lua https://github.com/vvanders/wasm_lua

Zelizz 9y ago
Oh man, with Lua in the browser, I'd actually start to write web stuff again. And we could get a really nice fast port of Love2D running!
- vvanders 9y ago
  Yeah, probably wouldn't be too hard. I've got Lua things drawing to an HTML5 canvas that runs at 60 FPS on a private project. As long as you don't make 1000's of calls per frame it runs pretty well.

ams6110 9y ago

> more secure Is it? How do we know? The attack surface in browsers is huge.

jfbastien 9y ago
A few ways that come to mind: 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.
- AnIdiotOnTheNet 9y ago
  And how long do you think that'll last? As developers stubbornly persist in trying to make desktop applications on the web, they'll demand more and more access to the host, and browser developers will give it to them in an effort to one-up each other. If anyone had actually cared about security on the web we wouldn't be where we are now.
  - jfbastien 9y ago
    Your phrasing leads me to believe that you distrust how web standards organizations approve new features? If that's not the case then I invite you to join the W3C Community Group and help avoid insecure additions w3.org/community/webassembly/
    - kuschku 9y ago
      That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG. And we already have a bluetooth stack for the web, USB drivers in JS, etc.
      - 9y ago

krapp 9y ago

>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. 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.

txdv 9y ago
Yeah, I wonder why OP thinks that the sandbox is bad. 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