We were building a game for Nickelodeon that was designed to run on the iPad 1 in the browser. The first pass of the game used Box2D for collision detection, under the assumption that they'd done a ton of work optimizing it with AABB trees/etc and everything would just work.
It didn't. The first version of the game was brutally slow and every time we did a touch collision detection, it would lag like crazy.
Out of frustration, we ripped out Box2D entirely and replaced it with naive O(n) box testing and hand-written motion code, thinking that we'd add in some optimizations later on to make it more performant. It turns out that this was fast enough without any further optimizations and we shipped it. The overhead of using a physics system was enough to bog down the iPad 1's poor non-JIT JS engine.
Fortunately there's enough spare cycles in modern tablets that a little bit of overhead from a physics engine isn't going to be a problem, although I'd wager there's a handful of Android tablets out there still as weak as the iPad 1.
What were the reasons for you to use the JS version of Box2D instad of the native version (with bindings)? In my experience, the native version runs just fine on low-end Android devices and the iPad 1.
It was a browser-only game so native code was not an option. The goal for them was to avoid app stores and give kids the ability to drop into games casually from the browser like they did with desktop flash at the time.
FWIW, I'm pretty sure Safari on iOS has always had a JIT, although web views embedded into App Store apps didn't have access to it for security reasons.
I am a tad surprised that Box2D only "Supports sweep-and-prune and brute force for broad phase collision detection." I've seen the world's simplest and most naive spatial grids work well enough for broad phase in production, and you can cook these up in 50 lines (or less) of code.
It didn't. The first version of the game was brutally slow and every time we did a touch collision detection, it would lag like crazy.
Out of frustration, we ripped out Box2D entirely and replaced it with naive O(n) box testing and hand-written motion code, thinking that we'd add in some optimizations later on to make it more performant. It turns out that this was fast enough without any further optimizations and we shipped it. The overhead of using a physics system was enough to bog down the iPad 1's poor non-JIT JS engine.
Fortunately there's enough spare cycles in modern tablets that a little bit of overhead from a physics engine isn't going to be a problem, although I'd wager there's a handful of Android tablets out there still as weak as the iPad 1.