jsoo certainly takes some getting used to, especially when it comes to actually having to care about the return types of things. Online documentation is painfully sparse and the ocaml type checker was vague at times, so there was quite a bit of trial and error. It does help that all the library bindings are parallel to their javascript counterparts.

Pattern matching with Ocaml is definitely a plus :P, but I definitely felt that working with Ocaml was substantially more challenging. Especially since none of us had prior experience in game development, much less functional game development, the code we produced was riddled with mutability. It would've helped to look at established design patterns first.

I personally found the jsoo documentation almost unusable (same with Ocsigen). OCaml still has a pretty serious shortage of up-to-date, descriptive documentation, especially outside the Jane Street Core bubble.

I'm really excited to see this project because it's the first jsoo program I've seen with a logical structure and a considerable amount of logic implemented in OCaml that ties into JS.

What would be the best way to throttle fps and ensure compatibility between different refresh rates?

You count the time since the last update, wait for the time to accumulate over the update threshold, run the update loop with a fixed time-slice enough times to match whole number of frames. Let the carry over perpetuate to the next frame.

At 144hz with a fixed time-slice set for 60hz, you'd have one update on the 2nd, 4th, 7th, 9th, 12th, 14th, etc. frames.

The best way is usually to not tie game state to frame ticks. See Bethesda's Creation Engine https://www.youtube.com/watch?v=Yuyp-S7FPNI for why that's a bad idea.

The movement is really hacky (https://github.com/mahsu/MariOCaml/blob/master/object.ml#L16...), whereas the actual game takes a more fine-tuned approach (http://s276.photobucket.com/user/jdaster64/media/smb3_physic...). It was tough to keep things simple and use a single set of rules without making everything too floaty or heavy.

I don't think "simple and use a single set of rules" describes the control code for any shipping (action) game. At least none I've worked on. They're all complex piles of special cases and hacks in an effort to make the movement 'feel' right (which works, but is disheartening at first, until you start to expect it).

The Sonic Physics Guide is how I implemented my first (good) platformer physics.

https://info.sonicretro.org/Sonic_Physics_Guide

It's fairly hack free in the abstract. But reality is often a little different, based on the quirks of your collision detection.