Basically, the title says it all. I've seen and worked with Django, Rails and a bit with Cake PHP. I'd like to know if there is a framework that is excellent for supporting casual, 2d, browser based game development. The closest that I've seen is flash, but I'd like to find something open source. Something that could handle both the graphics and communication to a database would be ideal. Any suggestions?
You need to keep track of two different concepts: Client side presentation and server side processing. If you are developing a casual flash-style game the complete game will probably be the client side presentation, mixed with some web services for highscore and the likes. However, if you want to do social-, mulitplayer- or mmo style games a lot, if not most of the game will be on the server to prevent cheating, and the client will just act like a dumb terminal. How that is handled is probably a topic for another question.
Of interest to anyone who wants to communicate in realtime between browser and server should be socket.io that is an abstraction on top of websockets with fallback using flash in older browsers.
There are several game engines/frameworks emerging with HTML5. Here are some links that might be of interest:
Apart from the Rocket Engine, these engines just cover the client side of a game. So there's no direct communication to a database (unless you're using something like Google Gears).
The thing is, in web development, a large part of the presentation would typically be done on the server side (using a framework that embeds some sort of templating system to output HTML to the client). If you want to do interactive game, a lot of the work has to happen on the client side (in the browser), so the problem is not so much how you generate HTML, but rather how you make things move on the user's screen.
For this client-side part, as mentioned, your choice are either Flash or JS (potentially using Canvas for modern browser).
For the client-server-db communication part, any of the technology you mentioned would be fine. The browser and server can communicate using classic ajax calls if you need.
I don't know of a framework that would handle both problems, but that's probably because they are really distinct, and happening on different side of the client-server mix.