That's not quite true. There are a number of languages which compile to JavaScript, e.g., Elm, and provide an API for interacting with the DOM, as well as some kind of FFI.
Couldn’t you use WebAssembly? I think (?) GP’s point is that it would make more sense to use a different language that compiles to WebAssembly. (Or transpile to Javascript I guess, but I don’t know why you’d do that.)
WebAssembly still doesn't have direct DOM bindings. That's at least two levels deeper and several more standards to go after the very basic Wasm GC that was only just recently standardized. For the moment you basically have an FFI/IPC bridge that you can send TypedArray buffers and attempt to UTF-8 decode them and then JSON.parse that on the JS side. (We don't even have strings agreed upon yet, mostly just arrays of bytes. Wasm Strings is a possible standard still in the process.)
Anyone doing serious HTML rendering with WebAssembly today A) has a build step, B) still has a bunch of JS to do memory buffer FFI/IPC and decoding/encoding, C) is usually using some form of Virtual DOM in the Wasm side and the JS side is some version of JSON-driven React/Preact-Lite. It is not today more efficient than React's build process nor React's runtime experience.
