I've had the pleasure of working with many different companies recently, each with very different business models, products and target users. However, a web application was integral to each organization's core product for every one of them. So, what approach should a developer take? That depends on your design objectives.

I've always said that before you can begin a project of any size, you must first decide which of the different design decision drivers you value most. Lets walk through some of the various decision drivers, and by the way, you may say that you're committed to all of these equally but there's no way your behavior will line up with that because it's not reality.

• Time to Market: if you've simply got to get it done as fast as humanly possible then you value this design driver most; be careful, however, since everyone wants to get something done as fast as possible, that when you declare the project "done" that you don't fall flat on your face because of the expectations you've set around trade-offs you made in not focusing enough on the other decision drivers in this list
• Scalability: if you don't expect to have a lot of traffic right out of the gate then you can probably ignore this one up front; again, be careful that you understand the implications of choosing a web app approach that may or not scale with dramatically different costs
• Agility: nearly every web app approach will claim to support rapidly prototyping and building out the solution one little piece at a time - don't believe it, there's a big difference among the various approaches when it comes to the scaffolding required to get things up and keep them up
• Extensibility: how hard will it be to make dramatic changes to the architecture and the approach without having to modify and/or write new code and how easy will it be to integrate new approaches and technologies
• Quality: how important is it that you know the quality of what you've created when you say it's "done"; notice I didn't make a statement about whether you'd accept high or low quality, this design driver is about whether you value taking the time to design a way to know the quality of what you've created at various milestones of the project
• Quality Control: how important is it that things work they way they were expected to; note that you cannot achieve quality control without having first taken the time to reliably understand what the quality of your product is at a given time
• Reliability: you may have a product with high quality but that is unreliable because the database goes down sometimes, or because services can't speak to one another occasionally, etc.
• Predictable Delivery Schedule: if you value this above other design drivers, your behavior will be completely different as you look to an approach to take
• User Experience: in my experience, few value this above others, but if you're one of the lucky few who does then you will care to choose a web app framework that makes it very easy to orchestrate the flow of control through a web application
• Application Lifespan: your app framework decision will definitely change if you know your application is going to live for many years to come
• Ease of Adding Resources: it's a lot easier to find talent to scale the team depending on the web app approach you take

Now, I will delineate some of the different approaches out there for creating web applications, and help specify which design drivers would compel the adoption of the approach.

1. Microsoft ASP .NET
   Strengths: Ease of Adding Resources, Predictable Delivery Schedule, Scalability, Application Lifespan, Quality, Quality Control
   
   You can't go wrong with a Microsoft platform. Maybe that will change in the future, but it's certainly not anytime soon. Choose this one if you want to pick a reliable approach which you'll be able to add talent to easily and if you're exclusively a Microsoft shop. If you're not exclusively a Microsoft shop, consider a different approach.
2. Old School Enterprise Java (J2EE)
   Strengths: Scalability, Predictable Delivery Schedule
   
   If you don't understand the difference between old school J2EE compared to the newer Enterprise Java (Java EE and EJB3) then read this excellent article. Basically, I wouldn't suggest this approach to anyone unless they inherited something they had to maintain and you should probably look to create a migration strategy to EJB3 as soon as possible.
3. New School Enterprise Java (EJB3, JPA, Annotations, etc.)
   Strengths: Scalability, Predictable Delivery Schedule, Quality, Quality Control, Extensibility, Application Lifespan, Reliability
   
   If you're going to have a product that will need to live for a long time with predictable schedules that scales linearly with more hardware then this is the pick for you. It's certainly not going to get you to market the fastest, even with excellent frameworks that build on top of it like Jboss Seam. If you're working at a big organization then this one will fit well.
4. Standard Java
   Strengths: Scalability, Quality, Quality Control, Extensibility, Reliability, Time To Market^
   
   There are many standard Java frameworks that don't rely on EJB's. It's not fair to say that they're all alike since they vary widely. However, having used several of them (Wicket, Stripes and Tapestry to name a few, I think it is fair to say that they are faster to develop than traditional Java Enterprise applications while enjoying many of the same benefits. However, the caret is next to Time to Market on this one because it's still very slow compared to some of the others. I'd pick this approach for smaller projects that likely don't need to live as long but would benefit from the extensibility and reliability of the approach.
5. PHP
   Strengths: Agility, Scalability, Extensibility, Time To Market, Ease of Adding Resources, User Experience
   
   Again, there are many PHP web app frameworks out there. PHP's strength lies in the low bar for getting in and cranking out web sites. However, this same low bar can open the door for creating poor quality applications by developers who lack the discipline necessary. I'd pick this one if time to market is your greatest concern bar none. However, if you're going to make a large web application with PHP make certain that you set standards around quality and code reviews and pay close attention to the contributors of the project.
6. Python
   Strengths: Agility, Scalability, Quality, Quality Control, Extensibility, Reliability, Time To Market
   
   Python traditionally provides more structure than on the PHP side making quality easier to measure and control, however it can be harder to find talent well versed in Python.
7. Ruby
   Strengths: Agility, Extensibility, Reliability, Time To Market, Ease of Adding Resources, User Experience
   
   Ruby is very similar to PHP in its strengths and weaknesses. Ruby is an excellent approach for getting it done fast.

In the end, no one approach is right for every project. In choosing an approach, I'd recommend first narrowing the list of candidates down to two or three and then taking the time to prototype a web application in each to determine which fits the best.