I'm building a JavaScript game in my own engine, which in retrospect was a big mistake considering the game utilizes a lot of multithreading (the game is "Noita meets Factorio" so it's required for the simulation). You can only share memory between threads using a SharedArrayBuffer with raw binary data and you need special headers from the web server to even enable it. This means that I've had to write a lot of convoluted code that simply wouldn't be necessary in a non-browser environment.
Other than that I really like that I can piggyback on the browser's devtools and that I can use the DOM for the UI.
Yes, this is a really good article that I can highly recommend if you're interested in these type of "falling sand" simulations.
A big difference between a classic powder toy game like in the article and Noita is that Noita needs to run a much larger simulation that extends beyond the visible canvas. So while multithreading is probably not needed in the former it's most likely needed when the game is a scrolling platformer. I posted a GDC talk by the Noita devs as a reply to a sibling comment if you're interested in their tech.
There are plenty of babylon.js & physics package demos around.
The WebGL support can be an issue on some machines, but when it does work... things like procedural fog/pseudo-procedural-water/dynamic-texture-updates look fairly good even on low-end gpus. Also, the free Blender addon can quickly export basic animated mesh formats that will save a lot of fiddling with assets later, and the base library supports asset loading etc.
Like all js solutions your top 3 problems will be:
1. Audio and media syncing (don't even try to live-render something like a face mocap)
2. Interface hardware access (grabbing keyboard/mouse/gamepads is sketchy)
3. Game cheats (you can't trust the clients world constraints are true)
4. web browser ram/cpu overhead
The main downside of using __any__ popular game-engine is asset extraction is a popular hobby for some folks (only consoles sort of mitigate this issue).
If you haven't played Noita it's basically a "falling sand" or powder physics game where every pixel is simulated. You need a special cellular automata that is not your typical game physics engine, so I don't think Babylon.js would be a good choice but I may be wrong.
We use multi threading in the netcode for our browser based games built in Godot. I've been considering looking into using web workers _without_ shared array buffer so that we can use threads in all environments, even without cross origin isolation. Is that something youve looked into?
Other than that I really like that I can piggyback on the browser's devtools and that I can use the DOM for the UI.