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).
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).
AssemblyScript initially targeted TS->WASM compilation, by only supporting a strict subset of the TS language. But at some point they dropped that idea and defined their own TS-like language. I don't know the reason for this, but my guess is that TS is too dynamic to just directly compile it to WASM?
Regarding Germany's official Corona tracing app (not the of this post), by the end of last year there was a discussion about collecting movement data of the app users [0]. The discussion was part of the "German Infection Protection Act", resulted in public protests and in the end got declined. I wonder what the state of this is in other countries?
There is a WebKit based HTML renderer called Ultralight. It works by creating hooks and intercepting the rendering calls of WebKit in order to allow embedding it easily.
Unfortunately the license of Ultralight is questionable, and it's not open-source either by bypassing the WebKit license (which is very questionable as well since WebKit itself is BSD-licensed).
Having such a project as a free open-source variant would be a huge game changer in my opinion.
The Ray-Tracing Extension is currently only available for Windows and Linux.
My next plan is to implement the extension into Dawn's D3D12 backend, so I can build chromium with my Dawn fork and have Ray-Tracing available directly in the browser (at least for myself) :)
Vulkan has a very verbose setup phase, but after that you only make some tiny calls here and there (Draw a frame, update some UBOs), so the CPU load isn't that high because you record most things at start-up.
Multi-threading is possible with SharedArrayBuffers [0] and N-API allows to take the memory address of it. NVK is only a thin layer above Vulkan and JavaScript <-> C++ interopability is pretty fast. You only notice some overhead when making thousands of calls, because the C++ code cannot be inlined. But again, this is not something common in Vulkan.
Also JavaScript doesn't have essential features like Compute shaders for years now. Vulkan has all of it. Even though WebGPU [1] is in development, I don't expect it to give access to the Vulkan RTX pipeline anytime soon.
I think this depends on the type of the product. It's important that the team allows and finds the right spot to restart with more focus on architecture and code quality to not loose motivation of later employees
construct-js uses DataView under the hood. I wrote construct-js to ease working with binary data by allowing you to name and reference sections, and handle things like endianess easily in one place. With a DataView, I still need to calculate offsets into a structure manually, whereas construct-js has .getOffset(name) and .getDeepOffset(path). If performance is key however, use the lowest level of course.
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.