I think web apps are dead anyway and the browser is heading towards being a legacy software. The future is small ephemeral UIs generated on the fly by LLMs that have access to datasources. WASM is too late.
And now that we're getting close to have the right design principles and mitigations in place and 0-days in JS engines are getting expensive and rare... we're set on ripping it all out and replacing it with a new and even riskier execution paradigm.
I'm not mad, it's kind of beautiful.
Isnt this what an OS is supposed to do? Mobile operating systems have done a pretty good job of this compared to the desktop OS.
audio can also have unending scope if you want to do physically simulated Spatial Audio.
Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping.
rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory.
The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.
One of my original motivations for creating Easel came from my experience playing (and making) webgames, which in general are coded in JavaScript (or TypeScript). I love webgames as a method of delivering multiplayer because the biggest problem is getting players, and I think the low-friction zero-download really helps with that. So this is the world I am trying to target. When I remade my old webgame in Easel, I found it to be many times more performant and am now able to target much lower spec devices. Not to mention, determinism is a non-issue now.
I get that some people are going to love Easel and some are going to hate it, and that's okay.
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending in Unreal - I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
FABRIK IK algo is a ~100 loc function.
Async coroutines in the way you are describing have terrible/unpredictable cache/memory access behaviour which leads to bad performance. Every time you switch coroutines you need load memory from (most likely) an unrelated region causing slowdowns.
All I can say is, probably not none.
And maybe a note on diminishing returns, in that we might want to reflect on the eradication of smallpox and the near total eradication of polio, and what it has meant to you and to your community to not really have to worry about those diseases.
If it is clearly personal and you do not have an objective answer then let this be a cause we can choose to donate to based on our personal assessment.