7 ms·

Hi, author of the article here. Happy to have a discussion about the WebAssembly component model and current implementations.

The_rationalist 5y ago
It's time to admit webassembly is a mistake and that GraalVM is an order of magnitudes superior technology and browser developers shouldn't have to make humanity suffer for eternity because of NIH syndrome and technical mediocrity.
bno1 5y ago
I get what components are supposed to do, but how does wasm currently talk with the browser and javascript code? Can it manipulate the DOM and execute asynchronously (like promises) or is it just a black box that receives some data and returns other data synchronously?
- matei_radu 5y ago
  By default, a WebAssembly module has no access to any host APIs — particularized for the web platform, a running module will have no way of accessing the DOM by default. When instantiating a module, it can use module imports [1], which can be used to access the DOM through JavaScript calls. [1]: https://webassembly.github.io/spec/core/syntax/modules.html#syntax-import https://webassembly.github.io/spec/core/syntax/modules.html#...
panic 5y ago
WebAssembly's type system supports just a handful of numeric types and opaque external reference types. How does WIT map its richer type system (which includes things like strings and records) onto these underlying types in a language-agnostic way?
- pjmlp 5y ago
  I guess they will need to rediscover the Common Language Subset of the Common Language Runtime and re-sell it as an invention.
PaulDavisThe1st 5y ago
So ... the Java model was: * define a VM, but not offer a public direct API * define a language that could be interpreted, compiled or JIT-compiled to the VM * implement the VM so that it could run standalone or in browsers * claim "write once, run anywhere" The WASM model appears to be almost identical, with the addition of: * offer compilation/translation from common existing languages Why should we prefer the WASM/WASI model to Java? Why should we believe it will be more successful? And perhaps more deeply, re-wrapping system APIs (e.g. POSIX) in WASM-specific modules seems incredibly time-inefficient (all those commitees, all that reimplemenation...). What if anything is going to be done to provide WASM/WASI with direct system access (outside the browser) ?
- panic 5y ago
  If you could Applet.instantiate() as easily as WebAssembly.instantiate() and have Java methods immediately available from JavaScript, I have no doubt that it would be as successful as WASM is. The advantage of WASM is that it’s already integrated with JavaScript VMs in a way that Java never was. Though I suppose it’s possible if someone wants to get V8 running JVM bytecode!
  - PaulDavisThe1st 5y ago
    So your argument there is "well, I can access WASM from javascript more easily that I could access Java" ? That's it?
    - panic 5y ago
      Yes—in most cases the technology itself doesn’t matter as much as how it can be deployed. The popularity of JavaScript itself is testament to that (though the technology has caught up quite a bit there).
  - pjmlp 5y ago
    Except it actually was, as there was an interop API for applets to interact with DOM and vice-versa.

The_rationalist 5y ago

It's time to admit webassembly is a mistake and that GraalVM is an order of magnitudes superior technology and browser developers shouldn't have to make humanity suffer for eternity because of NIH syndrome and technical mediocrity.

bno1 5y ago

I get what components are supposed to do, but how does wasm currently talk with the browser and javascript code? Can it manipulate the DOM and execute asynchronously (like promises) or is it just a black box that receives some data and returns other data synchronously?

matei_radu 5y ago
By default, a WebAssembly module has no access to any host APIs — particularized for the web platform, a running module will have no way of accessing the DOM by default. When instantiating a module, it can use module imports [1], which can be used to access the DOM through JavaScript calls. [1]: https://webassembly.github.io/spec/core/syntax/modules.html#syntax-import https://webassembly.github.io/spec/core/syntax/modules.html#...

panic 5y ago

WebAssembly's type system supports just a handful of numeric types and opaque external reference types. How does WIT map its richer type system (which includes things like strings and records) onto these underlying types in a language-agnostic way?

pjmlp 5y ago
I guess they will need to rediscover the Common Language Subset of the Common Language Runtime and re-sell it as an invention.

PaulDavisThe1st 5y ago

So ... the Java model was: * define a VM, but not offer a public direct API * define a language that could be interpreted, compiled or JIT-compiled to the VM * implement the VM so that it could run standalone or in browsers * claim "write once, run anywhere" The WASM model appears to be almost identical, with the addition of: * offer compilation/translation from common existing languages Why should we prefer the WASM/WASI model to Java? Why should we believe it will be more successful? And perhaps more deeply, re-wrapping system APIs (e.g. POSIX) in WASM-specific modules seems incredibly time-inefficient (all those commitees, all that reimplemenation...). What if anything is going to be done to provide WASM/WASI with direct system access (outside the browser) ?

panic 5y ago
If you could Applet.instantiate() as easily as WebAssembly.instantiate() and have Java methods immediately available from JavaScript, I have no doubt that it would be as successful as WASM is. The advantage of WASM is that it’s already integrated with JavaScript VMs in a way that Java never was. Though I suppose it’s possible if someone wants to get V8 running JVM bytecode!
- PaulDavisThe1st 5y ago
  So your argument there is "well, I can access WASM from javascript more easily that I could access Java" ? That's it?
  - panic 5y ago
    Yes—in most cases the technology itself doesn’t matter as much as how it can be deployed. The popularity of JavaScript itself is testament to that (though the technology has caught up quite a bit there).
- pjmlp 5y ago
  Except it actually was, as there was an interop API for applets to interact with DOM and vice-versa.