3 ms·

Because it’s not “devised to make JavaScript faster”. WASM is first and foremost designed as a compilation target for languages that work with a simple linear m

Because it’s not “devised to make JavaScript faster”. WASM is first and foremost designed as a compilation target for languages that work with a simple linear memory and don’t use a garbage collector, like C/C++/Rust (extensions to interact directly with the JavaScript GC are in progress, but quite a ways off). The progress it enables is the ability to run performance sensitive code written in these languages in a software-sandboxed environment at anywhere near native speed, as opposed to multiple times slower. Also neither the JVM nor the CLR even seriously attempt to offer the security when executing untrusted code that WASM does. WASM has been deployed for over a year in all the major browsers, making vulnerabilities in its implementations very valuable. Yet we haven’t seen some huge explosion of CVEs due to its addition, unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code).

lazyjones 8y ago
> unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code). Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.
- krapp 8y ago
  WASM was designed with the intent that it run in the web as well as natively[0]. It just happens that the technology is still in its infancy and, because initial support was deployed in browsers, the web is currently the primary focus of developer interest. And, unfortunately (to me) the most likely means of "native" deployment for WASM applications is going to be in Electron, but that's due to a limitation of the initiative of developer culture, not WASM itself. [0]https://webassembly.org/docs/non-web/ https://webassembly.org/docs/non-web/
  - lazyjones 8y ago
    IOW, JVM/CLR wanted primarily to support locally run, trusted application code and gave up on browser sandboxing. WASM is primarily run on browsers and hasn't attempted yet to support full applications. Apples vs. oranges.
    - krapp 8y ago
      I don't think it's apples and oranges, I think it's approaching the same destination from different starting points.
- johncolanduoni 8y ago
  I wasn’t claiming that they don’t have distinct feature sets; WASM for example can’t currently do any kind of shared memory concurrency, let alone provide a GC with shared memory concurrency. The claim that it’s just a recapitulation of the JVM however is equally innacurate. Nobody would seriously consider running multiple mutually-untrusted JVM programs in the same process, but WASM is offered in that manner in every major browser. That said, nothing stops a WASM embedder from offering system calls, and you can already use whatever system resources you want via Node as easily as you can use the DOM in a browser.

lazyjones 8y ago

> unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code). Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.

krapp 8y ago
WASM was designed with the intent that it run in the web as well as natively[0]. It just happens that the technology is still in its infancy and, because initial support was deployed in browsers, the web is currently the primary focus of developer interest. And, unfortunately (to me) the most likely means of "native" deployment for WASM applications is going to be in Electron, but that's due to a limitation of the initiative of developer culture, not WASM itself. [0]https://webassembly.org/docs/non-web/ https://webassembly.org/docs/non-web/
- lazyjones 8y ago
  IOW, JVM/CLR wanted primarily to support locally run, trusted application code and gave up on browser sandboxing. WASM is primarily run on browsers and hasn't attempted yet to support full applications. Apples vs. oranges.
  - krapp 8y ago
    I don't think it's apples and oranges, I think it's approaching the same destination from different starting points.
johncolanduoni 8y ago
I wasn’t claiming that they don’t have distinct feature sets; WASM for example can’t currently do any kind of shared memory concurrency, let alone provide a GC with shared memory concurrency. The claim that it’s just a recapitulation of the JVM however is equally innacurate. Nobody would seriously consider running multiple mutually-untrusted JVM programs in the same process, but WASM is offered in that manner in every major browser. That said, nothing stops a WASM embedder from offering system calls, and you can already use whatever system resources you want via Node as easily as you can use the DOM in a browser.