5 ms·

I don't know how useful that would be, it's still javascript (just a lower level version of it) after all. It's coupled pretty tightly with the browser.

Touche 10y ago
I think you're confusing asm.js with wasm. wasm is not JavaScript.
aspirin 10y ago
WASM isn't related to JavaScript in any way. Maybe you were thinking of asm.js? You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.
- 0xdeadbeefbabe 10y ago
  > You cannot access the browser APIs from WASM Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
  - smitherfield 10y ago
    Right now it's more like Flash or Java applets, running in a sandbox within a sandbox.
    - TazeTSchnitzel 10y ago
      Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).
      - hackcasual 10y ago
        Not exactly. You have to export those APIs into the WebAssembly module. It's certainly possible to have a WASM implementation that doesn't provide web APIs, but is still WASM.
  - aspirin 10y ago
    The high level goals of WASM do include access to browser APIs, but the MVP version that is being implemented now, does not yet allow it: https://github.com/WebAssembly/design/blob/master/JS.md https://github.com/WebAssembly/design/blob/master/JS.md WASM code can call external functions defined per module, and the external code can be JS code that interacts with browser APIs. So indirect use of browser APIs is possible.
- detaro 10y ago
  According to the docs, high-level goals of WASM are to allow synchronous calls to and from JavaScript; enforce the same-origin and permissions security policies; access browser functionality through the same Web APIs that are accessible to JavaScript; ? https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...
- s3th 10y ago
  Here's how to interact with browser APIs and import/export functions via the WebAssembly JS API: http://webassembly.org/getting-started/js-api/ http://webassembly.org/getting-started/js-api/
kibwen 10y ago
I've also linked this in a sibling comment to yours, but this post from the Rust project developers talks about a few of the potential upsides to a general-purpose compiler backend derived from the WASM initiative: https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275 https://internals.rust-lang.org/t/possible-alternative-compi... TL;DR: compilers written for the JIT use case are designed to minimize latency (compilation times) while still producing above-average code, so having such an alternative backend would be a boon for regular users of compilers with heavyweight backends (e.g. LLVM, which produces excellent code but at the cost of very large compilation times, even in unoptimized builds). Additionally, a compiler built to process WASM is more security-aware than your typical compiler, and thus won't include optimizations that attempt to exploit undefined behavior (thus losing out on potential optimizing opportunities, but hopefully producing code that's a bit more bulletproof).
rubber_duck 10y ago
As others said it has nothing to do with JS, i'd like to add how it's usefull - it's a low level VM spec (lower than say JVM or CLR) so it will hopefully be easy to compile various languages to it (hopefully because they need to fit a GC mechanism in to it yet to support higher level languages) but it's still safe/sandboxed and portable.

Touche 10y ago

I think you're confusing asm.js with wasm. wasm is not JavaScript.

aspirin 10y ago

WASM isn't related to JavaScript in any way. Maybe you were thinking of asm.js? You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.

0xdeadbeefbabe 10y ago
> You cannot access the browser APIs from WASM Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
- smitherfield 10y ago
  Right now it's more like Flash or Java applets, running in a sandbox within a sandbox.
  - TazeTSchnitzel 10y ago
    Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).
    - hackcasual 10y ago
      Not exactly. You have to export those APIs into the WebAssembly module. It's certainly possible to have a WASM implementation that doesn't provide web APIs, but is still WASM.
- aspirin 10y ago
  The high level goals of WASM do include access to browser APIs, but the MVP version that is being implemented now, does not yet allow it: https://github.com/WebAssembly/design/blob/master/JS.md https://github.com/WebAssembly/design/blob/master/JS.md WASM code can call external functions defined per module, and the external code can be JS code that interacts with browser APIs. So indirect use of browser APIs is possible.
detaro 10y ago
According to the docs, high-level goals of WASM are to allow synchronous calls to and from JavaScript; enforce the same-origin and permissions security policies; access browser functionality through the same Web APIs that are accessible to JavaScript; ? https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...
s3th 10y ago
Here's how to interact with browser APIs and import/export functions via the WebAssembly JS API: http://webassembly.org/getting-started/js-api/ http://webassembly.org/getting-started/js-api/

kibwen 10y ago

I've also linked this in a sibling comment to yours, but this post from the Rust project developers talks about a few of the potential upsides to a general-purpose compiler backend derived from the WASM initiative: https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275 https://internals.rust-lang.org/t/possible-alternative-compi... TL;DR: compilers written for the JIT use case are designed to minimize latency (compilation times) while still producing above-average code, so having such an alternative backend would be a boon for regular users of compilers with heavyweight backends (e.g. LLVM, which produces excellent code but at the cost of very large compilation times, even in unoptimized builds). Additionally, a compiler built to process WASM is more security-aware than your typical compiler, and thus won't include optimizations that attempt to exploit undefined behavior (thus losing out on potential optimizing opportunities, but hopefully producing code that's a bit more bulletproof).

rubber_duck 10y ago

As others said it has nothing to do with JS, i'd like to add how it's usefull - it's a low level VM spec (lower than say JVM or CLR) so it will hopefully be easy to compile various languages to it (hopefully because they need to fit a GC mechanism in to it yet to support higher level languages) but it's still safe/sandboxed and portable.