Rendering UIs in webgl is fairly user-hostile. No accessability, no extensions, no custom styles, ...

Yes it keeps coming up, yet Flash will have its revenge.

For a smallish subset of use cases, maybe. But replacing the DOM with a canvas-based UI for general use would be reinventing many of the problems of Flash.

Many designers and game devs see it otherwise.

Gamedev is a separate topic. As for designers, they are on the opposite side from users in the tug-of-war of control over content rendering. I don't believe they should get 100% of their way.

Gamedev falls squarely into my "smallish subset of use cases". It does legitimately need non-DOM UI, but it's not a huge part of the Web (yet).

As for designers, thank you for finding a much more diplomatic phrasing than the one I was about to write.

WebGL bindings are on the same footing as DOM bindings- they're not an alternative in this sense, because insofar as we have one we already have the other.

No because accessing WebGL contexts directly from WebAssembly, specially WebGPU ones, is something that keeps coming up in some Chrome presentations.

And thanks to many, including HN readership, Chrome and Safari are the only browsers that many businesses care about nowadays.

What I'm saying is, the feature/mechanism that lets WebAssembly call WebGL or WebGPU is exactly the same one that lets it call DOM APIs. The same implementation work supports both.

I looked into their WebAssembly demo, but it doesn't seem to use WebGL, just a regular DOM (with an ungodly number of elements).

That was just an example, maybe not the best one.

I should just have linked something done in Unity instead.

Uno uses DOM bindings, not WebGL.