3 ms·

Wait, is that never going to happen? I was so excited when WASM was first announced, but then lack of DOM access killed it for me. It was supposed to allow us t

Wait, is that never going to happen? I was so excited when WASM was first announced, but then lack of DOM access killed it for me. It was supposed to allow us to use any language instead of just JS.

flohofwoe 1y ago
You can access the DOM from WASM just fine, you just have to go through a JS shim because the DOM is a Javascript API (just like WebGL, WebGPU, WebAudio and any other API available in browsers). In most DOM access libraries (like https://github.com/web-dom/web-dom https://github.com/web-dom/web-dom) this Javascript shim exists but is completely invisible to the library user (e.g. it looks and feels as if WASM would have direct DOM access). Why this topic is always brought up I really have no idea, at this point it feels like trolling attempts because from a technical point of view 'direct DOM access from WASM" simply doesn't make a lot of sense. Accessing web APIs from WASM is an FFI scenario, no matter how you look at it.
- lenkite 1y ago
  Actually DOM implementations are all in C++ and DOM interfaces are described in WebIDL. So direct DOM access from WASM is indeed possible if browser vendors chose to open the same. Access via a JS shim is just utterly destroying performance - orders of magnitude worse than mere FFI - and all the trolling attempts are the one pretending otherwise.
  - dfabulich 1y ago
    Browser vendors can't simply "choose" to open direct DOM access to WASM. When defining standardized DOM APIs in WebIDL, WebIDL assumes that you can use JavaScript strings, JavaScript objects + properties, JavaScript Exceptions, JavaScript Promises, JavaScript garbage collection, and on and on and on. Almost all of the specification of WebIDL itself is about the dozens of types that it assumes the platform already provides. https://webidl.spec.whatwg.org/ https://webidl.spec.whatwg.org/ WebAssembly doesn’t have any of those things. As a low-level VM, it supports only modules, functions, bytes, numbers (32-bit and 64-bit integers and floats), arrays (called “tables”), and opaque pointers (“reference types”). No one has ever standardized a DOM API for low-level languages. You’d presumably need to start by defining a new low-level WebIDL design language just to define a low-level DOM API. Defining WebIDL itself has taken decades. Today, the browser vendors aren’t convinced that a new low-level DOM API is worth their time. It’s better to make existing JS web apps faster than it is to begin a multi-year (multi-decade?) project to make a new thing possible that could be better in the long run.
    - lenkite 1y ago
      There is the Web Assembly Component Model. Nothing is really preventing browser vendors from exposing a WASM host interface to DOM, exposing it as a Component Model interface. This would allow DOM functions to be invoked from WASM without hand-written/generated JS glue code. Nobody is really calling for exposing the full-suite of WebAPI's. But basic DOM access allowing manipulation of page elements would be immediately leveraged by all the WASM-UI frameworks available today. Framework authors would throw out all the generated JS glue code which adds painful overhead pronto with great joy.
      - flohofwoe 1y ago
        Tbh, the WASM Component Model is first and foremost an overengineered mess which probably will add more overhead than a handwritten JS shim just because it is so complex. In the end you'll need to marshall datatypes from one language into another, and that is already a mess between 'native' languages (e.g. a C++ std::string is something entirely different than a Rust or Kotlin String). So in that hypothetical native WASM DOM API, how do you pass something as simple as a string? Let's say the obvious solution would be a ptr/length pair, but then, what encoding UTF-8? UTF-16? UTF-32? No matter what the solution is, you won't find a data representation that directly matches the string representation in all the languages that compile to WASM, so you'll need to do marshalling anyway before calling that hypothetical WASM DOM API. And suddenly the current 'low-tech' solution of letting a JS shim extract the string data from the WASM heap and build a JS string before calling into a web API suddenly doesn't look so terrible anymore. A much more impactful change would be to add more WASM-friendly entry points to web APIs. For instance there's no reason that WebGPU is so 'Javascript object heavy' or uses strings as enum values except that this is common in other Javascript APIs. If WebGPU had additional "WASM-friendly" functions which use plain numbers (as object handles or enum values) a lot of the marshalling overhead when being called from WASM would simply go away.
        lenkite 1y ago
        Calling it an over-engineered mess when it solves a complex problem through well-defined specification and semantics is very poor posturing. The WASM specs are actually FAR easier to read and grok than most of the legacy WebAPI's! Many of these problems are already being solved. For strings, the rules are: The string is encoded as UTF-8. The ABI lowers it into a (ptr: u32, len: u32) pair in linear memory. The receiving component or adapter then uses the (ptr, len) to read the UTF-8 bytes and convert it back into its own string representation. Modern languages that already have UTF-8 strings don't need to pay extra costs. Even old languages like Java are moving to UTF-8 now. Compact Java strings are already UTF-8. No, the JS shim way is the terrible mess that adds a ridiculous amount of overhead and a truck load of hacks to obtain limited performance. Just have a look at the code for wasm-bindgen for the very definition of messy-engineering and awkward workarounds to get things running.

Wait, is that never going to happen? I was so excited when WASM was first announced, but then lack of DOM access killed it for me. It was supposed to allow us to use any language instead of just JS.

flohofwoe 1y ago

You can access the DOM from WASM just fine, you just have to go through a JS shim because the DOM is a Javascript API (just like WebGL, WebGPU, WebAudio and any other API available in browsers). In most DOM access libraries (like https://github.com/web-dom/web-dom https://github.com/web-dom/web-dom) this Javascript shim exists but is completely invisible to the library user (e.g. it looks and feels as if WASM would have direct DOM access). Why this topic is always brought up I really have no idea, at this point it feels like trolling attempts because from a technical point of view 'direct DOM access from WASM" simply doesn't make a lot of sense. Accessing web APIs from WASM is an FFI scenario, no matter how you look at it.

lenkite 1y ago
Actually DOM implementations are all in C++ and DOM interfaces are described in WebIDL. So direct DOM access from WASM is indeed possible if browser vendors chose to open the same. Access via a JS shim is just utterly destroying performance - orders of magnitude worse than mere FFI - and all the trolling attempts are the one pretending otherwise.
- dfabulich 1y ago
  Browser vendors can't simply "choose" to open direct DOM access to WASM. When defining standardized DOM APIs in WebIDL, WebIDL assumes that you can use JavaScript strings, JavaScript objects + properties, JavaScript Exceptions, JavaScript Promises, JavaScript garbage collection, and on and on and on. Almost all of the specification of WebIDL itself is about the dozens of types that it assumes the platform already provides. https://webidl.spec.whatwg.org/ https://webidl.spec.whatwg.org/ WebAssembly doesn’t have any of those things. As a low-level VM, it supports only modules, functions, bytes, numbers (32-bit and 64-bit integers and floats), arrays (called “tables”), and opaque pointers (“reference types”). No one has ever standardized a DOM API for low-level languages. You’d presumably need to start by defining a new low-level WebIDL design language just to define a low-level DOM API. Defining WebIDL itself has taken decades. Today, the browser vendors aren’t convinced that a new low-level DOM API is worth their time. It’s better to make existing JS web apps faster than it is to begin a multi-year (multi-decade?) project to make a new thing possible that could be better in the long run.
  - lenkite 1y ago
    There is the Web Assembly Component Model. Nothing is really preventing browser vendors from exposing a WASM host interface to DOM, exposing it as a Component Model interface. This would allow DOM functions to be invoked from WASM without hand-written/generated JS glue code. Nobody is really calling for exposing the full-suite of WebAPI's. But basic DOM access allowing manipulation of page elements would be immediately leveraged by all the WASM-UI frameworks available today. Framework authors would throw out all the generated JS glue code which adds painful overhead pronto with great joy.
    - flohofwoe 1y ago
      Tbh, the WASM Component Model is first and foremost an overengineered mess which probably will add more overhead than a handwritten JS shim just because it is so complex. In the end you'll need to marshall datatypes from one language into another, and that is already a mess between 'native' languages (e.g. a C++ std::string is something entirely different than a Rust or Kotlin String). So in that hypothetical native WASM DOM API, how do you pass something as simple as a string? Let's say the obvious solution would be a ptr/length pair, but then, what encoding UTF-8? UTF-16? UTF-32? No matter what the solution is, you won't find a data representation that directly matches the string representation in all the languages that compile to WASM, so you'll need to do marshalling anyway before calling that hypothetical WASM DOM API. And suddenly the current 'low-tech' solution of letting a JS shim extract the string data from the WASM heap and build a JS string before calling into a web API suddenly doesn't look so terrible anymore. A much more impactful change would be to add more WASM-friendly entry points to web APIs. For instance there's no reason that WebGPU is so 'Javascript object heavy' or uses strings as enum values except that this is common in other Javascript APIs. If WebGPU had additional "WASM-friendly" functions which use plain numbers (as object handles or enum values) a lot of the marshalling overhead when being called from WASM would simply go away.
      - lenkite 1y ago
        Calling it an over-engineered mess when it solves a complex problem through well-defined specification and semantics is very poor posturing. The WASM specs are actually FAR easier to read and grok than most of the legacy WebAPI's! Many of these problems are already being solved. For strings, the rules are: The string is encoded as UTF-8. The ABI lowers it into a (ptr: u32, len: u32) pair in linear memory. The receiving component or adapter then uses the (ptr, len) to read the UTF-8 bytes and convert it back into its own string representation. Modern languages that already have UTF-8 strings don't need to pay extra costs. Even old languages like Java are moving to UTF-8 now. Compact Java strings are already UTF-8. No, the JS shim way is the terrible mess that adds a ridiculous amount of overhead and a truck load of hacks to obtain limited performance. Just have a look at the code for wasm-bindgen for the very definition of messy-engineering and awkward workarounds to get things running.