I think we're missing the bigger more important point here. Some of the early posts mentioned go back to the drawing board and design your game first. This is the crucial first step that makes or breaks the majority of all projects out there. Without a good design document and a solid plan for what your trying to make you won't get anywhere no matter what technology you learn or how many people your recruit.
Beyond that you should have at least a basic understanding of how the internet and web pages work to understand some design limitations that you will have to stick to. First off is the most important part, you need to realize that a web page runs in 2 environments. First on the server through some server side programming language like PHP. At this stage your page / site or game can do logic on the server side. You can access the database, read other players stats and what not. This is the hub of anything that needs to be interactive (as in the player need something from the game or from another player).
Once the server is done doing all it's magic it will then send files to the client (or your players web browser). Your web browser downloads these files, displays text, images and effects and executes javascript code (ON THE PLAYERS MACHINE). From here your javascript can NOT access stuff on the server directly. You can not get another players stats, you can not write to top scores file, all you can do is manipulate what's in memory (for this page) and edit the contents of the page.
You CAN send requests to the server, let it do something and give you a response. Use that response to edit something on the page and continue. You can even download other images, send and receive multiple requests and manipulate the page all at once using async methods that are standard practice in javascript now adays. It's just important to know that your game exists in two places at once and that each side can only do things in it's own area. The server can only send files to the client it can't listen for clicks or button presses. The client side can't read or write to your database (but it can ask the server to get some results).
Once you have a good understanding on that (wherein you completely understand what I just said) your ready to get started. This is when you want to get off the forums, turn off the computer and start scribbling in your note pad. (Ok you can use Open Office). You want to write up at least a dozen pages or more before you even start considering anything else. You want to know what is the general game progression, who / what can the player control, how do you play the game, what is the objective to win, how in game puzzles or quests will work and any other important main line game systems.
Yes it is more important to have a good design document explaining your game than it is to know anything about web development. Even if you are the best web programmer in the world if you have no clue what your building it just won't work for you. On the good side of things though once you have over 12 pages written and you have answered the majority of the questions in the previous paragraph you will be able to start scouting technologies. It will be easier to figure out what you need to do and what you can use to get it done. I would still recommend getting an experienced programmer to make these calls for you but even he/she will need the design document to know what they need.
So in short your first step in developing a web based game is to first learn the limitations of the web. Second write out a HUGE design document, something easy to read informative and helpful. Something you can give to me so that I understand how all of the mechanics of your game work, something that I can read and actually visualize the game in my head. Once you have that then you'll be ready to start addressing the necessary technologies, engines, frameworks and so on.