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.
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
I use them in a Vulkan API for node.js to handle 64bit interopability when mapping Vulkan memory. Mapping Vulkan memory returns you a numeric address to the memory region. To handle the address I use BigInt, which can then be used to create an ArrayBuffer as a direct JS-side memory view where you can write e.g. your texture data into. See [0] how its used on node-side and [1] the C++ implementation using the V8 API
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.