4 ms·

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

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?
- Fluorescence 1y ago
  (still not a browser engineer - others will know better). It doesn't need to be the same API... but implementing a new DOM API that doesn't meet the w3c standard is a bit on the nose. It's meant to be language independent hence the IDL. Looking into it, the IDL might insulate the existing API implementation from JS to a greater degree than I assumed above. Apparently there might be horrors lurking in the binding generation code though. You can poke around in blink: https://github.com/chromium/chromium/blob/main/third_party/blink/renderer/core/dom https://github.com/chromium/chromium/blob/main/third_party/b... > isn't Dom access in essence an ability to change html tree It might be more accurate to look at it the other way: our current DOM implementations were created to implement the "DOM API Standard". The standard dictated the types and how reading/mutation works. > need type mappings I can't imagine how it can avoid type mappings for things like e.g. creating unattached bits of DOM or binding callbacks that receive bits of DOM. Personally I might be happy for a tiny WASM api... but then foresee 10 years of maddening omissions, security bugs and endless moaning because they didn't just implement the standard everyone already knew.
  - yencabulator 1y ago
    > It's meant to be language independent hence the IDL. This in the same conversation where people are saying the DOM API is intrinsically tied to Javascript!

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?

Fluorescence 1y ago
(still not a browser engineer - others will know better). It doesn't need to be the same API... but implementing a new DOM API that doesn't meet the w3c standard is a bit on the nose. It's meant to be language independent hence the IDL. Looking into it, the IDL might insulate the existing API implementation from JS to a greater degree than I assumed above. Apparently there might be horrors lurking in the binding generation code though. You can poke around in blink: https://github.com/chromium/chromium/blob/main/third_party/blink/renderer/core/dom https://github.com/chromium/chromium/blob/main/third_party/b... > isn't Dom access in essence an ability to change html tree It might be more accurate to look at it the other way: our current DOM implementations were created to implement the "DOM API Standard". The standard dictated the types and how reading/mutation works. > need type mappings I can't imagine how it can avoid type mappings for things like e.g. creating unattached bits of DOM or binding callbacks that receive bits of DOM. Personally I might be happy for a tiny WASM api... but then foresee 10 years of maddening omissions, security bugs and endless moaning because they didn't just implement the standard everyone already knew.
- yencabulator 1y ago
  > It's meant to be language independent hence the IDL. This in the same conversation where people are saying the DOM API is intrinsically tied to Javascript!