And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever seen say - js is significantly slower.
One example is the techempower benchmarks Fortune section[0]. It's a fairly basic app, but it tests a full stack web app in multiple languages, and it's pretty clear that js is fimrly in the middle of the pack, far behind the compiled options. If you have any sources to the contrary, I'd love to see them.
Maybe not .net, but I've worked on 3D graphics in the browser and can say with confidance that rewriting your app in C or C++ could see orders of magnitude perf increase over JS.
Comparing a pure js implemention to code using opengl or webgl, I imagine several orders of magnitude difference is likely.
But a decent js implemention of 3D graphics-something would use one of the available tools for such applications. Making the difference considerably smaller.
I've worked with a couple of the 'decent JS implementation of 3D graphics' libraries and, although they're not all like this, the ones I used were not built by people with experience doing low-level performance work. As such, they made some poor architectural decisions that prevented users of the libraries from doing some very basic optimizations that would have increased perf significantly.
The three major blockers I remember were:
1. Render contexts are created on the main thread and the user of the library gets no control over this. This means all driver overhead and library function calls block the main thread, which matters a lot when trying to hit 8ms/frame.
2. Loading textures asynchronously (in another thread, not Javascript async/await) was straight up impossible due to poor architecture. This means app startup was 500ms instead of 5ms. Maybe not a big deal to you, but our use case necessitated quick (a few frames at worst) startup.
3. The renderer used a scene graph, which was hilariously slow to traverse for large numbers of objects. Impossible to optimize by anyone as far as I can tell. Scene graphs just don't work well in JS.
