My favourite bit of JavaScript game dev from 2004 was DHTML Lemmings (http://www.elizium.nu/scripts/lemmings/) - a great implementation of Lemmings, including destructible terrain, without canvas/webgl!
Jake Gordon at Codeincomplete.com has lots of great write ups about javascript game development. It's worth checking out. Start with the pong implementation to see the most basic parts of a game including game loop, painting to canvas, and collision detection. http://codeincomplete.com/games/
The game this tutorial is based on was done in late 1996 for Netscape Navigator 3.0 (which was introduced in September, I think, and allowed you for the first time to change the image source attribute). The whole point of the code laid out in the tutorial was about being fast enough to do it in realtime. (E.g., string operations and string comparisons were slow and even crashed Netscape 3.0 on a PowerMac [bringing down the whole machine], when there were too many too fast, or avoiding function calls, which were expensive, too.)
The granularity of animations was actually limited by bandwidth and dial-ups then commonly in use. There's a demo [1] for smooth animations for NS 3, achieving sub-animation by the image equivalent of 8-bit programmable character-set animation. But this would have been to heavy in load/bandwidth to be used for a full featured game.
DHTML came in August 1997 (NS 4.0 and layers) and would finally let you do you whatever you wanted (or rather, some of it). Also, both JavaScript and average machines had become a little faster by then (but there were a few surprise in JS 1.2, like minus zero).
[Edit:] A real issue with early browser games was the amount of available screen estate. Average screens were 12"@72dpi (640 × 480), leaving a quite small usable space when taking into account the space occupied by the task bar, the menu bar, the quite heavy window chrome of the browser, etc. (No way to squeeze a full featured Pac-Man layout into the remaining area.)
Before Netscape 3, there were some visual interactive games that were typically running in a textarea element as ASCII animations, since this was the only spacial element that could be directly manipulated by JS. I remember an Invaders game done this way, very much like http://www.masswerk.at/termlib/sample_invaders.html but in black on white in a textarea. (Another way to do animations was to write a new document into a frame, but this was too slow for interactive realtime games, aka "video games".)
(Mind the small maze for 640 x 480 screen sizes and the unusual connection of the "teleports" to add a bit of complexity to the maze layouts. There was another, even earlier implementation to this one, but I don't have the sources anymore.)
Maybe interesting backstory: The games (JS-PacMan and an Invaders game) were done explicitly as demos for brand-able browser games, but – while listed in all those "What's cool" directories of the day – marketing people didn't catch the idea of games in the browser then. I ended up providing the Invaders game for free to USA Today Marketplace (they opted for the Pac-Man game first, but settled on the Invaders game for legal concerns), since there wasn't a commercial market for this.
(Some years later, all those mails like, "I need this for my homework, can I have it?", started to drop into my mailbox, this is, why there is the tutorial. That's also why there are some gaps left in the tutorial, meant to force people to do their own, rather than just copying the code.)
Ironically, when the originally iPhone came out, the game was just up to date again, in terms of screen size, performance requirements, and touch-friendly input. There were means to transfer it onto the iPhone and someone sold a pirated version on CD as a dedicated iPhone game.
This is a tangent, but does anyone know the max number of sprites you can have animated in JavaScript before it gets sluggish on a typical computer running Chrome?
