If you're building a game for the browser, then there are two major factors you need to key in:
1) You'll have to master JavaScript
2) Putting all your logic in the front-end makes your game significantly more hackable.

There are alternatives to #1 (ActionScript being one of them; I feel this is a technology which is losing traction to HTML5 so can't recommend going this route). Google's Native Client would also be a good bet, since C code becomes reusable; this, however, is even more bleeding-edge than HTML5 game development, and its future is highly uncertain.

As for #2, the main option is to put game logic in the back-end, and link the browser game client via some means like XmlHttp requests, WebSockets, and the like.

I've gone the Canvas+WebSockets client/server route, upon which I'm basing TGE's development (link in sig). Game development in this fashion is in its infancy at best, meaning there aren't complimentary libraries (higher-level network messaging, stateful machines, sprite animation, level formats or generators, user interface widgets, and so on), but I'm slowly working on them.

Flash/AS, obviously, give you a neat little black-box SWF, user interface, and (probably) established game engines (see these 11) already, but the trade-off is (what I refer to as) a dying technology (YMMV). It's really a matter of what you want to accomplish moving forward.

Drop me a line if TGE interests you.