The reason I asked is because I've worked on several large commercial 3D WebGL games which ran into the issues I described. Yes you can get a complex game running at <=16ms per frame, but GC and compiler operations make it hard to achieve consistently smooth performance. This is even more noticeable in VR.
> You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery.
No. If you create large scale real-time JS apps, you will soon run into the issues I described.
Scale is a very wishy-washy term. You can build complex applications with JS, you just need to move the scale out of the main loop. Don't run business logic alongside your render, or else you will indeed run into these problems.
This advice isn't unique to Javascript and goes back to Carmack hacking on Doom, Wolfenstein 3D, and beyond. It's just that Javascript makes it easy to shoot yourself in the foot here, because this isn't a role that was forseen when JS was designed.
Do you have any links to share? I'd love to learn more about these performance problems you describe.
On platforms that support it, depending on how big the GC stalls are (extrapolation isn't magic) and it's not really something you should be triggering regularly by design. Async reprojection was invented to mitigate the fact that a variable frame rate makes you sick in VR so really it's evidence to support the parents case. If you're regularly dipping into async reprojection due to the GC then a trade off between visual accuracy/artifacts and the GC is being made.
> You can basically do anything you can imagine. It just requires a bit more thought and learning than copying and pasting jQuery.
No. If you create large scale real-time JS apps, you will soon run into the issues I described.