4 ms·

Those libs/frame works would benefit massively from WASM DOM access.

by tcfhgj 4y ago

irrational 4y ago
But, why? You would have to recompile the WASM code every time a change was made to the DOM. Add a new DIV that you now need to address? Add a reference to it in the WASM code and recompile. What a pain that would be.
- gspr 4y ago
  I don't understand. Can you elaborate?
- HexDecOctBin 4y ago
  A div's name is equivalent to a pointer to a widget in a GUI library. HTML isn't some special sauce, we've known how to do GUI in C/C++ for a long time.
flohofwoe 4y ago
I doubt it. What would "DOM access in WASM" even look like? The DOM is exposed as a tree of high level Javascript objects with properties, but WASM has no notion of objects, properties and their relationship, it only has a few integer and floating point primitive types and heap addresses. All that "DOM access from WASM" would mean is that there's a new primitive "external reference" type which allows to tunnel an opaque Javascript object reference through WASM and back to JS while pinning the JS object for the JS garbage collector. But one couldn't really do anything useful with that reference on the WASM side without calling through JS (AFAIK there are some very high level proposals for this too, which could basically create the required JS shim code automatically, but that would just add more runtime complexity for little actual gain - the same shim-generation work could be done offline in the compiler toolchain). All that the "external reference" type would enable is a slightly simplified Javascript shim, because it would no longer need to map index handles to Javascript objects. But that's just a small part of what the JS shim does. It's a bit like asking if x86 machine code has support for the Win32 window system API, the answer is both 'yes' and 'no' ;)
- 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).

Those libs/frame works would benefit massively from WASM DOM access.

by tcfhgj 4y ago

Those libs/frame works would benefit massively from WASM DOM access.

But, why? You would have to recompile the WASM code every time a change was made to the DOM. Add a new DIV that you now need to address? Add a reference to it in the WASM code and recompile. What a pain that would be.

gspr 4y ago
I don't understand. Can you elaborate?
HexDecOctBin 4y ago
A div's name is equivalent to a pointer to a widget in a GUI library. HTML isn't some special sauce, we've known how to do GUI in C/C++ for a long time.

flohofwoe 4y ago

I doubt it. What would "DOM access in WASM" even look like? The DOM is exposed as a tree of high level Javascript objects with properties, but WASM has no notion of objects, properties and their relationship, it only has a few integer and floating point primitive types and heap addresses. All that "DOM access from WASM" would mean is that there's a new primitive "external reference" type which allows to tunnel an opaque Javascript object reference through WASM and back to JS while pinning the JS object for the JS garbage collector. But one couldn't really do anything useful with that reference on the WASM side without calling through JS (AFAIK there are some very high level proposals for this too, which could basically create the required JS shim code automatically, but that would just add more runtime complexity for little actual gain - the same shim-generation work could be done offline in the compiler toolchain). All that the "external reference" type would enable is a slightly simplified Javascript shim, because it would no longer need to map index handles to Javascript objects. But that's just a small part of what the JS shim does. It's a bit like asking if x86 machine code has support for the Win32 window system API, the answer is both 'yes' and 'no' ;)

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