> but yeah it can't yet interface directly with the DOM

The Spritely folks are doing DOM manipulation from Scheme in Wasm, is there something beyond this that you're referring to? https://spritely.institute/news/building-interactive-web-pag...

When people say "can't yet interface directly with the DOM," the "directly" is the key bit. Projects in webassembly have been able to interact with the DOM forever, but they need to do it via JavaScript shims. I am not intimately familiar with Spritely, but from reading the post briefly, it appears this is exactly what they're doing:

  Scheme.load_main("hello.wasm", {}, {
    document: {
      body() { return document.body; },
      createTextNode: Document.prototype.createTextNode.bind(document)

This requires boilerplate and adds overhead that would not exist if it were able to be done "directly."

I suspect as time goes on we'll see more and more of this become direct through optimization. My understanding is that this already happens for certain well-known methods, like if you import Math.sin or something V8 is going to optimize it to a direct call when it compiles the Wasm module that imports it. And maybe a non-JS interface will emerge, but there needs to be some kind of layer that preserves capability security. You wouldn't want any and every Wasm module to have access to the entire browser API. You will still want the ability to omit capabilities, attenuate them, etc. and for that a full programming language seems necessary and well... JS is already there.

Are there plans to add DOM support? That seems pretty critical for what I had thought wasm was supposed to be myself.

Wasm allows for importing host functions. Those host functions could provide DOM access. With Wasm GC it is possible to pass external references (DOM nodes, promises, etc.) to and from Wasm. What this looks like in practice is that a thin JS bootstrap script instantiates the Wasm module, passing along a set of JS functions that map to the declared Wasm imports and then the program is effectively driven from Wasm at that point.

I'm not sure. All I know is that there are some hurdles to get past. One of them is that several DOM APIs were created specifically for JavaScript, which is...really disheartening.

WASM in the browser can do exactly one thing aside from what is in WASM spec - interface with JavaScript.

It's not even that slow to interface with JS from WASM if you do it right (i.e. you aren't passing strings back and forth).