Is there a good way of doing a proper "game loop" in browser based JS? All the examples I've seen use timers, and worse suggest you use lots of different timers for different animated objects, which sounds like a recipe for overhead and inconsistency.
In Windows, I've seen people use WM_TIMER messages to do animation, but the much better way is to rewrite the main application message loop to include updating the animation, but that won't work in something that's totally event driven. And presumably if you go into an endless loop in JS, the browser is going to treat that as a hang.
In Flash, being frame based, you can have an onEnterFrame event that's triggered at the frame rate of the movie, which at least means everything runs consistently even if it can sometimes get behind if the renderer can't keep up.
Well, the main application message loop is just a thing that relinquishes control whilst it waits for events to arrive - otherwise, the first app you ran would consume 100% CPU busy-waiting. On a multi-tasking OS, all applications are event-driven, even if the event is the implicit one of being given a timeslice that allows an endless loop to have another go at running to infinity.
For JS, you don't need to think about the main application message loop: that's already in existence in the host context, outside the scope of your code (e.g. in the browser process or, for something like node.js, in a server process) and all you deal with is the messages that are dispatched to your code, which in the case of the browser consist of user interaction events (e.g. the user has moved the mouse over something), network interaction events (e.g. an image has loaded, or an XMLHttpRequest has undergone a state transition), and timer events (interval timer X invokes its callback). These events are all provided by the external context (note that setInterval and setTimer are both methods of the window object, not functions native to the language), which is why JS can easily be deployed in other contexts such as servers (where the events are things like "a remote host connected" or "a disk-based file has been opened and can now be read"). Either way, callbacks are king: whilst the script is being parsed it can do stuff if the context provides for it (e.g. document.write() in browsers, and the creation of variables having global scope) but after that, everything happens as callbacks from the context's event loop.
Personally, I prefer a setup that makes it clear that your code is running as and when things happen that it needs to deal with. (Any attempt to create an endless loop in JS in a browser will result in the browser stepping in and prompting the user that a script is running for too long; otherwise, Denial of Browser attacks would be all over the web.)
JS in the browser doesn't have the concept of frame refreshes, because stuff like that is abstracted away into the browser's rendering engine, which will take care of all the aspects of rendering like double-buffering and clipping content to containing views.
Incidentally, one of the reasons that Flash can be "The best way to tell if your laptop's fan still works" is that ActionScript is constructed on the same principles, but many Flash devs can't seem to get their heads around the idea of creating applications that consist entirely of callbacks; instead, they create busy-waiting loops which consume loads of CPU. The fact that Flash allows this is one of its greatest failings. It should just kill stuff that busy-waits beyond a certain time; then the errant devs would have to learn to do it properly, or be out of a job. But it doesn't, so they aren't, so Flash is a scourge. I've found great inner peace since I blocked it
