@pancakes@zvava I think a part of it is that most people doing something complex in WASM gravitate towards POSIX-like stuff, which might stick until there is some clear model of how we actually want interfaces to behave
@natty@pancakes afaik anyway, actually interfacing with the dom directly is outside of the scope of wasm because designing those interfaces (from a mess of constantly growing legacy apis to "machine code") is a giant logistical nightmare especially if you want to standardize them, doubly especially when we already have an incredibly fast and flexible programming language specifically for dom manipulation
@zvava@pancakes yeah but that's like one of the hundreds of things JS does. I am for example wondering if WebGPU wouldn't be more interesting directly inside WASM
DOM much less so but if you're gonna make that boundary annoying, people will start making UI toolkits that don't use the DOM, which is much worse
@natty@pancakes people already have from some rust toolkit using a webgl renderer and i forgot the name of if but it has a demo with a bunch of shit in it that i was having a very hard time finding flaws in, idr what the affordances to accessibility in it were (if literally any at all lol) but it's already out there and more performant than any other ui i've seen in the browser which loops back around to why i don't think wasm should even rlly be a thing bc it opens the pandora box for all this bs but its ok bc the web is beyond repair atp anyway so who rlly cares :3
@pancakes@solonovamax i mean it has its merits (fast non-standard crypto, interfacing directly w graphics apis, etc) but js was designed from the ground up to make web pages dynamic and wasm was designed for demanding computational tasks, so trying to force the latter to do the job of the former makes no sense, the interop is required because wasm is an entirely separate tool to js fit for an entirely separate purpose
