This technology is actually pretty fast. Drawing images is so fundamental for browsers that it tends to be heavily optimized. If your hardware runs well Google

This technology is actually pretty fast. Drawing images is so fundamental for browsers that it tends to be heavily optimized. If your hardware runs well Google Maps, it will run well this engine (and also the other very similar one - Aves from Dextrose). Rendering wise, it's the same technology. Most of heavy lifting is done by compiled code of the browser, JavaScript just sets few parameters (as opposed to canvas, where you "micromanage" rendering in relatively slow scripting language). One screenful of map is about 80-100 images, though performance wise there is still quite a lot of breathing room. I did some stress tests and my notebook can easily handle many hundreds individual image sprites (done as absolutely positioned DOM elements). Now physics, this may be slow to do in JavaScript. But with a type of games that work well with image sprites (basically anything where building blocks are large), this will probably not make too big problems as you will not have that many interacting objects (at once together at screen) and also interaction will be optimizable. The "killer app" will probably be tile based strategies or role-playing games (see current top Facebook apps), so physics / pathfinding / AI would only need to deal with discrete grids, not some costly pixel precise collision detection.