3 ms·

I've been reading about this for a while. Will it. Won't it. Does anybody know why is it such a big problem to add dom access to wasm? In worst case, we shou

I've been reading about this for a while. Will it. Won't it. Does anybody know why is it such a big problem to add dom access to wasm? In worst case, we should have a second option to Js (which is not typescript - typescript is just a lipstick on a pig). If wasm is not it, why not something different? Having dart in would be great.

flohofwoe 1y ago
> Does anybody know why is it such a big problem to add dom access to wasm? Well, the article does a pretty good job of answering this specific question ;)
- wongarsu 1y ago
  Does it? It gives good reasons why we can't have specific parts. Having the JavaScript Standard library in WebAssembly would be hard (was anyone actually asking for that?), and some of the modern APIs using promises or iterators wouldn't have a clear mapping. Also not everything could be zero-copy for every language But the article doesn't do a very good job explaining why we can't have some dom access, at least for the 90% of DOM APIs not using JavaScript-specific features. Most of the argument boils down to "you shouldn't want direct DOM access, because doing that would be work for these people, and we can instead have those other people do lots of work making the JavaScript bridge less painful. And anyways it's not clear if having these people make proper APIs would actually result in faster code than having those people do a separate sophisticated toolchain for each language" It reads very much like a people and resource allocation problem rather than a technical challenge
  - flohofwoe 1y ago
    > at least for the 90% of DOM APIs not using JavaScript-specific features The DOM is a Javascript API, so it uses 100% Javascript-specific features (every DOM manipulation requires accessing JS objects and their properties and lots of those properties and function args are Javascript strings) - none of those map trivially to WASM concepts. It's a bit like like asking why x86 assembly code doesn't allow "C++ stdlib access", the question doesn't even make much sense ;)
    - wongarsu 1y ago
      I wouldn't call having objects and properties Javascript-specific. The article details how they were initially written with support by both Java and JavaScript in mind. Now WASM isn't object oriented like Java or JavaScript, but the concept of objects maps very cleanly to the concept of structs, member functions to simple functions that get the struct as first parameter (optionally with an indirection through a virtual function table) and properties to getter/setter functions. I suppose you would have to specify a struct memory layout for the purpose of a WASM DOM API, which may or may not be zero-copy for any given language. Or is there something in the browser architecture that requires them to be JavaScript objects with the memory layout of the JavaScript engine, rather than just conceptually being objects?
      - Fluorescence 1y ago
        IANABE (not a browser engineer) On the one hand, JS DOM objects are idl generated wrappers for C++. In theory we can generate more WASM friendly wrappers. On the other, the C++ code implementing the API will be tightly coupled to the entire JS type system and runtime. Not just the concept of an object but every single design decision from primitives to generators to dynamic types to prototypical inheritance to error handling... Also, I believe the C++ DOM implementation itself is pretty tightly integrated with javascript and it's memory management e.g. nodes have references into the managed heap to use JS objects directly like EventListeners and js functions. Creating a new non-JS DOM API doesn't sound intractable to me... but browsers annihilate my assumptions so it's probably millions of hours of effort and close to a rewrite...
        wongarsu 1y ago
        Those are great points. That's the angle I was missing from the article
        criticalfault 1y ago
        But why would it need to interact with Js or having the same API? Maybe I misunderstood, but isn't Dom access in essence an ability to change html tree? Since this is wasm, why would it need to reimplement js API and need type mappings? Couldn't it be something different?

flohofwoe 1y ago

> Does anybody know why is it such a big problem to add dom access to wasm? Well, the article does a pretty good job of answering this specific question ;)

wongarsu 1y ago
Does it? It gives good reasons why we can't have specific parts. Having the JavaScript Standard library in WebAssembly would be hard (was anyone actually asking for that?), and some of the modern APIs using promises or iterators wouldn't have a clear mapping. Also not everything could be zero-copy for every language But the article doesn't do a very good job explaining why we can't have some dom access, at least for the 90% of DOM APIs not using JavaScript-specific features. Most of the argument boils down to "you shouldn't want direct DOM access, because doing that would be work for these people, and we can instead have those other people do lots of work making the JavaScript bridge less painful. And anyways it's not clear if having these people make proper APIs would actually result in faster code than having those people do a separate sophisticated toolchain for each language" It reads very much like a people and resource allocation problem rather than a technical challenge
- flohofwoe 1y ago
  > at least for the 90% of DOM APIs not using JavaScript-specific features The DOM is a Javascript API, so it uses 100% Javascript-specific features (every DOM manipulation requires accessing JS objects and their properties and lots of those properties and function args are Javascript strings) - none of those map trivially to WASM concepts. It's a bit like like asking why x86 assembly code doesn't allow "C++ stdlib access", the question doesn't even make much sense ;)
  - wongarsu 1y ago
    I wouldn't call having objects and properties Javascript-specific. The article details how they were initially written with support by both Java and JavaScript in mind. Now WASM isn't object oriented like Java or JavaScript, but the concept of objects maps very cleanly to the concept of structs, member functions to simple functions that get the struct as first parameter (optionally with an indirection through a virtual function table) and properties to getter/setter functions. I suppose you would have to specify a struct memory layout for the purpose of a WASM DOM API, which may or may not be zero-copy for any given language. Or is there something in the browser architecture that requires them to be JavaScript objects with the memory layout of the JavaScript engine, rather than just conceptually being objects?
    - Fluorescence 1y ago
      IANABE (not a browser engineer) On the one hand, JS DOM objects are idl generated wrappers for C++. In theory we can generate more WASM friendly wrappers. On the other, the C++ code implementing the API will be tightly coupled to the entire JS type system and runtime. Not just the concept of an object but every single design decision from primitives to generators to dynamic types to prototypical inheritance to error handling... Also, I believe the C++ DOM implementation itself is pretty tightly integrated with javascript and it's memory management e.g. nodes have references into the managed heap to use JS objects directly like EventListeners and js functions. Creating a new non-JS DOM API doesn't sound intractable to me... but browsers annihilate my assumptions so it's probably millions of hours of effort and close to a rewrite...
      - wongarsu 1y ago
        Those are great points. That's the angle I was missing from the article
      - criticalfault 1y ago
        But why would it need to interact with Js or having the same API? Maybe I misunderstood, but isn't Dom access in essence an ability to change html tree? Since this is wasm, why would it need to reimplement js API and need type mappings? Couldn't it be something different?