Is WPF development faster or slower than classic ASP.NET (web forms)

Question

Are you experienced with both ASP.NET and WPF coding? If so, I'll be grateful if you'll share your experience, please.

We are estimating a 100-screen WPF project. Our estimation methodology involves characterizing the complexity of each screen. We then apply a standard number for the development time, based on the complexity and the technology. The standard number is based on the developer being good, not a super-star.

For example, here's a screen:

The user selects a row in the master grid, then edits the data in the detail and saves the changes. Ajax is used to populate and save the detail without a postback. The data layer is already there, and styling will be handled by someone else. The task includes writing an appropriate suite of unit tests; integration testing is separate.

We would characterize this screen as medium and allocate X hours for the task, for classic ASP.NET (as opposed to MVC).

We need help figuring out what X should be for WPF.

My question:

If the screen was being created in WPF, by someone good at WPF -- would it take X hours, or .7 X, or 1.3 X? What is the relative productivity of WPF vs classic ASP.NET?

Asking another way: If a task takes (picking a number) 10 hours of ASP.NET coding, how many hours would it take to do it with WPF? 5? 15?

We'd like to know if WPF is (picking a number) 50% more productive than ASP.NET, so we can propose a lower price and be confident that we will be able to do the project within budget.

[Edit] Asking yet another way: This discussion ASP.Net or WPF (C#)? has a bunch of responses. The selected "correct" answer is "Reasons to choose WPF" and the first reason is "Much faster and easier development than ASP.NET and jQuery".

Is that answer true? How much faster?

Answer 1

From personal experience:

ASP.NET is easier to get into than WPF. ASP.NET quite similar to other web server side technologies. WPF breaks with and adds many features to classic desktop development, that takes time getting used to.

That said, actual development by experienced developers might be a lot faster in WPF. My personal stress factor is browser compatibility (getting it to render exactly the same way in multiple (versions of) browsers; it simply takes too much time.)

You are not going to get any numbers from me as it is much to hard to give them based on the input you have given.

Answer 2

There are too many variables. The number 1 reason to pick a tool is because of user familiarity. If your team already knows and is comfortable with ASP.NET it will be several magnitudes better and faster using that. If your team does not know WPF, then there will be a ramp up period, and once they are fully ramped up, they will probably be just as fast as they were with ASP.NET.

However, if the requirement is that the app can be installed, or is needed offline, or has some other benefit that only comes with WPF, then you probably need to take the hit. If not, you'll have a more quality product if you let the team use the tools they are comfortable with.

If you are trying to keep your concerns separated and doing a Model View Presenter style approach with asp.net, I think that takes longer and is more work than MVVM in WPF, because there is great support for binding. But still, there is a learning curve.

There is nothing implicit to asp.net or WPF that makes one more rapid than the other. What determines the speed of development is the talent of the team and what they are comfortable with.