This unfortunately introduces a lot of overhead and doesn't scale well for larger applications. WebGL calls are already incredibly slow compared to native, and the trampolining between WASM and JS world adds on top.

When WASM got released (around 2017), there was already that discussion to allow direct bindings without a JS roundtrip, but AFAIK there is still no actual implementation for this in any browser.

WebGL is slower than native mainly because of the additional security-validations compared to a native GL driver, e.g. it cannot simply forward calls into the underlying 3D-API but instead WebGL needs to take everything apart, look at each single piece to make sure it's correct, reassamble everything and then call the underlying 3D-API (roughly speaking).

The calling overhead between WASM and JS is quite negligable compared to that (at least since around 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...).

Another problem is that WebGL relies on garbage collected Javascript objects, but this problem can't really be solved on the WASM side, even with the "anyref" proposal (this would just allow to remove the mapping layer between integer ids and Javascript objects that's currently needed).

Doesn't seem to stop MS with Blazor (.Net), Rust, and a few others from doing this. Also, there are plenty of games running in web assembly using bindings for things like WebGL and openal via similar bindings. As far as I know the current situation is pretty workable already and getting better. E.g. garbage collection is coming pretty soon.

I guess it depends on what you are doing. For most people doing web assembly, the point is avoiding dealing with/minimizing the need for interacting with javascript. But still, it seems there are some nice virtual dom options for Rust: https://github.com/fitzgen/dodrio that are allededly fast and performant (not a Rust programmer myself).