These engines generally don’t use the DOM; instead, they render in a canvas element and provide you a framework to deliver logic and drawing instructions to each frame before it renders. That’s an entirely web-standards-compliant approach as Canvas was meant for this. There is stock code and art out there to save you time creating in-game objects for any particular engine (my personal preference is Phaser. )
Thanks, dylz. I think I am not interested in high-performance graphics, so I am not sure I am fond of working only with the <canvas>, even with these abstracted game engines.
I might just sit for a day to write beautiful CSS and use animeJS or something like that to go back to DOM approach of doing this.
FWIW, I am doing something similar right now and I can tell you that making thousands of overlapping divs sucks for performance already on desktop, and is even worse on mobile. I can see why the canvas thing is in use.
Most JS game engines should support firing native events of some sort, like you should theoretically have the ability to call window.confetti() from canvas-rendering game code in response to a victory screen or similar.