Nice, thanks for the link. I hadn't heard the term "rubber banding" before, but that exactly describes what I end up with.

I think my backend and overall strategy are good, sending events rather than state, deterministic simulation, event buffering, client prediction, etc, ultimately my issues arise on the client side when using these frameworks, I haven't found one that considers how a game server operates, so it ends up requiring a good deal of hacking to inject server messages into the game state at the right places, and ultimately the math is always a little bit off, rounding issues add up, rubber banding appears, etc. I guess I could write my own engine from the ground up with a backend in mind, but I don't have the free time to make the engine and the client and the server and the actual game, so I was hoping that maybe Melon2 would have considered my use case.

I find that the bigger engines give you much better equipment to succeed with multiplayer. I think smaller engines avoid it as it’s easy to declare it out of scope and therefore avoid the pain.

Also, a piece of advice I once heard that resonated with me: you either make a game engine or a game. Never both.

I am also working on JS client-server multiplayer implementations, and I've gone with WebRTC for the transport and a state-based communication (instead of events). The primary reason is to avoid desyncs, which is in my opinion impossible to avoid with JS because of the different JS engines and platforms that the game will run on. If you're expecting determinism when playing across mobile ARM, desktop x86, desktop ARM, and any combination of these, then the only way to achieve this is to use fixed point math and reimplement the behavior of JS primitives such as arrays and hash tables. It might be worth it for you and the game you're making, but for fast action games this is not needed, and just sending state to the players should work well.