3 ms·

> The DOM is exposed as a tree of high level Javascript objects with properties, I don't understand the reasoning. Of course it should be exposed in a way that

by tcfhgj 4y ago

> The DOM is exposed as a tree of high level Javascript objects with properties, I don't understand the reasoning. Of course it should be exposed in a way that best fits into WASM tech

flohofwoe 4y ago
The entire concept of the DOM (-API) is built around the Javascript object model, which is on a totally different abstraction level than WASM. It's like asking to create a CPU which can directly run Javascript, and on top has special instructions to "manipulate the DOM". It just doesn't make much sense on a practical level. Creating a library in a high level language which wraps DOM manipulation makes a lot more sense, and nothing in WASM prevents this (and the rest are just implementation details of the library).
- gspr 4y ago
  Does the question make sense on the level of sandboxing, though? I thought part of the problem was that the WASM VM doesn't even have access to the DOM itself?
  - flohofwoe 4y ago
    The WASM VM can only communicate with the outside world through what is essentially a jump table of "Javascript FFI functions" (or native functions for WASM VMs that run outside the browser), and those functions can only have simple arguments and return values like integers and floats (no pointers, no strings, no structs, no object references, etc...). Creating a Javascript object on the "JS side" requires a mapping of the Javascript object to a simple WASM integer type (usually this is performed by the JS shim by storing the object in a dictionary with the integer handle as key). The integer handle is then passed back to the WASM side. Whenever WASM wants to call a Javascript API function involving a JS object, it passes the integer handle back to the Javascript shim, which looks up the associated JS object in the dictionary, and so on and so forth... One proposed improvement is to be able to directly tunnel Javascript object references as "opaque handles" through WASM, so that the object dictionary housekeeping code wouldn't be necessary. The whole thing seems terribly convoluted, but its not much different than FFI mechanisms where a very high level language needs to call into C APIs (just reversed).

by tcfhgj 4y ago

> The DOM is exposed as a tree of high level Javascript objects with properties, I don't understand the reasoning. Of course it should be exposed in a way that best fits into WASM tech

flohofwoe 4y ago

The entire concept of the DOM (-API) is built around the Javascript object model, which is on a totally different abstraction level than WASM. It's like asking to create a CPU which can directly run Javascript, and on top has special instructions to "manipulate the DOM". It just doesn't make much sense on a practical level. Creating a library in a high level language which wraps DOM manipulation makes a lot more sense, and nothing in WASM prevents this (and the rest are just implementation details of the library).

gspr 4y ago
Does the question make sense on the level of sandboxing, though? I thought part of the problem was that the WASM VM doesn't even have access to the DOM itself?
- flohofwoe 4y ago
  The WASM VM can only communicate with the outside world through what is essentially a jump table of "Javascript FFI functions" (or native functions for WASM VMs that run outside the browser), and those functions can only have simple arguments and return values like integers and floats (no pointers, no strings, no structs, no object references, etc...). Creating a Javascript object on the "JS side" requires a mapping of the Javascript object to a simple WASM integer type (usually this is performed by the JS shim by storing the object in a dictionary with the integer handle as key). The integer handle is then passed back to the WASM side. Whenever WASM wants to call a Javascript API function involving a JS object, it passes the integer handle back to the Javascript shim, which looks up the associated JS object in the dictionary, and so on and so forth... One proposed improvement is to be able to directly tunnel Javascript object references as "opaque handles" through WASM, so that the object dictionary housekeeping code wouldn't be necessary. The whole thing seems terribly convoluted, but its not much different than FFI mechanisms where a very high level language needs to call into C APIs (just reversed).