Comment by wongarsu | Hacker News Reader

Comment by wongarsu | Hacker News Reader

Parent Full thread

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

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

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?

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

Those are great points. That's the angle I was missing from the article

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?

(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/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.

> 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!

Sure an automatically generated JS shim which marshalls between a web API and the WASM module interface is possible, but that's still not direct DOM access, it still goes through a JS shim. The detail that this JS shim was automatically generated from an IDL instead of manually written is really not that important when the question is "does WASM allow direct DOM access", the simple answer is "no".

The underlying problem is that you need to translate between a Javascript-idiomatic API and whatever is an idiomatic API in the language you compile into WASM, and idiomatic C, C++, Rust, ... APIs all look very different so there isn't a single answer. It's not WASM being relevant here, but the high level source language that's compiled into WASM, and how well the DOM JS API (and the Javascript concept it is built on) map to APIs for various 'authoring languages'.

The whole problem is really quite similar to connecting two higher level languages (e.g. Rust and C++) through a C API (since this is the common interface that both Rust and C++ can talk to - but that doesn't mean that you can simply send a Rust String to the C++ side and expect that you automatically get a std::string - this sort of magic needs to be explicitly implemented in a shim layer sitting between the two worlds) - and to use the string example, there is no such thing as a WASM string, instead how string data is represented on the WASM side depends on the source language that's compiled to WASM.

If you push the shim to JavaScript then it isn't direct DOM access. But you could push the shim into the C++ browser code, providing one DOM API to JavaScript and slightly smaller shimmed version to WASM. Then you cut out the JavaScript middle-man and can call it "direct DOM access".

Of course you couldn't provide idiomatic versions for every language, but the JS shims also can't really do that. Providing something close to idiomatic C would be a huge step up, the language libraries can then either offer a C-like API or choose to build new abstractions on top of it

> But you could push the shim into the C++ browser code

That's easier said than done because of details like that you can't build a JS string on the C++ side, the translation from string data on the WASM heap into a JS object needs to happen on the JS side.

But this is how all the Emscripten web API shims work, and they do this quite efficiently, and some of those shims also split their work between the JS and C/C++ side.

So to the programmer it does look like with Emscripten there's direct access to the (for instance) WebGL or WebGPU APIs, but in reality there's still quite a bit of JS code involved for each call (which isn't a problem really as long as no expensive marshalling needs to happen in such a call, since the call overhead from WASM into JS alone is really minimal).

Reply on news.ycombinator.com