Productivity: WebForms vs. WinForms

[Martin Rosén-Lidholm]

Although an impossible question to answer, I fell urged to raise it anyhow.



Given a fairly complex ERP application scenario, what's your estimation for
the X-ratio



dev. time for WebForms app

----------------------------------- = X

dev. time for WinForms app



?



My own experiences tell me that it should be about 2, but peers differ in
opinion. Some agree, some says 1, and some says 3...



Regards,

// Martin Rosén-Lidholm



PS Sorry for the cross post, but I really would like to hear both camps'
views on this subject.

 

[Martin]

Hi Martin,

In my view, this aspect of the development should be driven from the
requirements than the timescales.

Naturally existing skill set plays a part, but deployment and maintenance
are significant differences between these technologies.

I would guess you have an ulterior motive for asking this question.

Martin

 

[Martin Rosén-Lidholm]

Martin,

Thank you for your reply.

No, my motives aren't ulterior ;-)

I've come to the conclusion that the functional and non-functional
requirements of the project at hand can be met with both technologies.

Since I believe it'll take us twice the time using WebForms (the skill set
is very diverse and not in favor of any of the two), I'd like to notify
management about this.

However, my belief isn't shared, so I tried to broaden the discussion base
with this thread.

// Martin

 

[Martin]

If you were your own boss, which would you use? (Sounds like windows
forms).

Who's going to use the system, and how many users to you have?

Do you have a brief system spec you'd like to share with us?

Martin

 

[Martin Rosén-Lidholm]

Inline.

If you were your own boss, which would you use? (Sounds like windows
forms).

- WinForms, for productivity reasons.

Who's going to use the system, and how many users to you have?

- Between 15 and 500 users per site/customer.

- We also have personas identified where the super users are prio 1.

Do you have a brief system spec you'd like to share with us?

- I'd say "Template 1A Enterprise Resource Planning" (order, inventory,
invoicing, and purchase) with detail and summary views, search, reporting,
and so forth.

- In other words; nothing unique other than our deep knowledge of the domain
at hand.

// Martin

 

[Martin]

I suppose the question is can you foresee a situation where they would want
to use it over the internet?

Unless you design it accordingly, it will run like a dog over VPN. WebForms
would encourage good remote performance from the start.

Also you might reap long term benefits if you build on top of web
services. - integration with suppliers and other business partners?

Martin

 

[Guest]

I don't know that I'd say it's 2:1. I think there are a lot of factors
involved, but I think someone quite comfortable with WebForms will have
little difficulty matching the productivity of a winform developer for the
same app, with some qualifications...

The qualificatiosn include things like, will the web version require special
controls that the winform version won't? Will you need to be transferring
data from the user's local machine? If so, that adds a measure of
complexity.

If you're talking a simple business data-entry application type thing, I
don't think a webform is inherently more complex, or at least not
significantly so. Certainly not 2X, maybe 1.2X. But this assumes equal skill
sets in both.

There are significantly different considerations with each, though.

There's no question that the maintenance aspect of a web app is much lower,
though. You don't have to worry about different machine configurations and
such which can always lead to maintenance nightmares for WinForm apps. You
don't really have to worry about anything (like the .NET framework) being
installed on the user's machine. They simply need to have a web browser
that's compatible. So, from a maintenance side, you can generally save a ton
of time = money going with web forms.

That said, I do primarily WinForm apps because I prefer the responsive
experience to the web experience, and I think a lot of people feel that way,
but I can turn out web apps about as fast as I can winform apps. But if I'm
doing something for a customer with lots of users and I have the choice, I
go with WebForms.

Pete

 

[Martin Rosén-Lidholm]

My main concern is productivity, although maintenance and responsive GUI are
two *very* important aspects as well.

I have quite a lot of experience with web development with both rather fat
DHTML clients making RPCs and more traditional ASP solutions. In terms of
user experience, the first is possible to make close (but definitely no
cigar!) to the rich experience you can expect from a Windows app but take
very much time to develop. The second gives the user a very poor GUI but is
fairly equal in development costs (given a much poorer GUI as stated). I
have no commercial experiences with ASP.NET.

My main concern is that I'd like to give the users a reasonably rich user
experience. The way I see it, compared to a two-tiered WinForm solution with
all layers but the DB in the client, I must add a web server, the complexity
of maintaining state in a stateless environment (HTTP), duplication of
business logic (real time validation), ... Hence my 2:1 ratio.

Don't get me wrong - I really do want to be wrong about the productivity
issue, but I can't see how added complexity won't increase development time.

// Martin

I don't know that I'd say it's 2:1. I think there are a lot of factors
involved, but I think someone quite comfortable with WebForms will have
little difficulty matching the productivity of a winform developer for the
same app, with some qualifications...

The qualificatiosn include things like, will the web version require special
controls that the winform version won't? Will you need to be transferring
data from the user's local machine? If so, that adds a measure of
complexity.

If you're talking a simple business data-entry application type thing, I
don't think a webform is inherently more complex, or at least not
significantly so. Certainly not 2X, maybe 1.2X. But this assumes equal skill
sets in both.

There are significantly different considerations with each, though.

There's no question that the maintenance aspect of a web app is much lower,
though. You don't have to worry about different machine configurations and
such which can always lead to maintenance nightmares for WinForm apps. You
don't really have to worry about anything (like the .NET framework) being
installed on the user's machine. They simply need to have a web browser
that's compatible. So, from a maintenance side, you can generally save a ton
of time = money going with web forms.

That said, I do primarily WinForm apps because I prefer the responsive
experience to the web experience, and I think a lot of people feel that way,
but I can turn out web apps about as fast as I can winform apps. But if I'm
doing something for a customer with lots of users and I have the choice, I
go with WebForms.

Pete

Inline.

If you were your own boss, which would you use? (Sounds like windows
forms).

- WinForms, for productivity reasons.

Who's going to use the system, and how many users to you have?

- Between 15 and 500 users per site/customer.

- We also have personas identified where the super users are prio 1.

Do you have a brief system spec you'd like to share with us?

- I'd say "Template 1A Enterprise Resource Planning" (order, inventory,
invoicing, and purchase) with detail and summary views, search, reporting,
and so forth.

- In other words; nothing unique other than our deep knowledge of the domain
at hand.

// Martin

Martin


message Martin,

Thank you for your reply.

No, my motives aren't ulterior ;-)

I've come to the conclusion that the functional and non-functional
requirements of the project at hand can be met with both technologies.

Since I believe it'll take us twice the time using WebForms (the

skill
set

is very diverse and not in favor of any of the two), I'd like to notify
management about this.

However, my belief isn't shared, so I tried to broaden the

discussion
base

 

[Martin Rosén-Lidholm]

I find myself in the same situation as Espen Antonsen judging from this
quote:
"As a web developer I find many tasks more time consuming and difficult to
accomplish when building a web application - we develop a web-based ERP
system."

http://sleepyhead81.blogspot.com/2004/06/web-browser-changes-wanted.html

Regards,
// Martin Rosén-Lidholm

My main concern is productivity, although maintenance and responsive GUI are
two *very* important aspects as well.

I have quite a lot of experience with web development with both rather fat
DHTML clients making RPCs and more traditional ASP solutions. In terms of
user experience, the first is possible to make close (but definitely no
cigar!) to the rich experience you can expect from a Windows app but take
very much time to develop. The second gives the user a very poor GUI but is
fairly equal in development costs (given a much poorer GUI as stated). I
have no commercial experiences with ASP.NET.

My main concern is that I'd like to give the users a reasonably rich user
experience. The way I see it, compared to a two-tiered WinForm solution with
all layers but the DB in the client, I must add a web server, the complexity
of maintaining state in a stateless environment (HTTP), duplication of
business logic (real time validation), ... Hence my 2:1 ratio.

Don't get me wrong - I really do want to be wrong about the productivity
issue, but I can't see how added complexity won't increase development time.

// Martin

 

[mortb]

I definitely second the notion that it's much harder build web applications
that provide a decent user experience!
What I'd develop in one day using winforms I sometimes find myself doing for
1/2 week using webforms and still the GUI is nowhere near the GUI a win
form would provide.

The main problem is that HTML is not made for building applications, it's a
format for displaying text.

If I'd restart my current project I'd look into making a winform client
communicating with webservices instead as it would be easier to write and
easier to use.
It's not true that you don't have to consider the user's configuartion when
riting a web app. What works in your browser will not always work for in
users.

/mortb

 

[Rob Nicholson]

However, my belief isn't shared, so I tried to broaden the discussion base

with this thread.

Are you getting "it must be a web app" stance even though it'll take
longer and possibly be less functional?

Rob.

 

[mortb]

Nowadays many solutions get developped as webapps just becuase it's thought
of as beeing much easier to develop,
for the users to get access to, scalable and that they have a greater
compabillity -- "it must be a web app".

These points are true for building non e.g complex applictaions that just
list data.

If you want to provide a really good user experience and fairly complex
behaviour. you have to be and qualified in
HTML-authoring,
asp.net coding,
java script coding,
cross-browser issues,
IIS-configuration,
and possibly Webdesign, SQL, XML and XSLT.

If you want a rich usr experience it's not just to grab som webcontrols and
drop them on a page like you wolud do in the much more mature winforms
environment.
You can buy some custom webcontrols but you don't know which will work and
which wont?
With all these different issues you'll easily head wrong at some part of the
project.

I say either webapps have to get easier to build and use or we'd be better
off going back to the fat client winforms "roots".

/mortb

 

[Martin Rosén-Lidholm]

Yes, exactly.

"Win apps are not modern."

All requirements points towards a WinForms app, the users have .NET FW and
WinXP, and with ClickOnce the major technical argument (deployment) for
WebForms falls short.

// Martin

 

[Rob Nicholson]

Nowadays many solutions get developped as webapps just becuase it's
thought

of as beeing much easier to develop,
for the users to get access to, scalable and that they have a greater
compabillity -- "it must be a web app".

True, "easier to develop" by those who don't know better

With all these different issues you'll easily head wrong at some part of the
project.

Ohh that can happen with any application!

I say either webapps have to get easier to build and use or we'd be better
off going back to the fat client winforms "roots".

There *must* be some middle ground. Ignoring "web apps are easier to
develop" (they're not), the other issues have to be tackled which is access,
compatability and support costs (zero footprint).

When I first read about Java applets, I thought a solution was in the
offering. It still might be as opinion about the feasibility of large
complex web applications is questioned. The idea of walking up to any PC,
logging in as myself and small applets starting to download across the
Internet seems feasible to me. For example, a new PC has almost no software
installed. I hit the Word icon and enough Java code is downloaded to display
the toolbars etc. Start typing and the code to spell check is downloaded in
the background. Open a file and that's opened from the Internet and then
cached locally for speed.

The problem with my dream is that in practise is really hard to break down
that application yourself into Java applets. It would be far better if the
operating system/language did that behind the scenes - maybe the entire
application is 50MB big but the O/S doesn't load the whole lot - it just
pulls down the bits it needs over a slow link, maybe even as individual
methods are executed.

It feels like it could work...

It's not called Windows though!

Cheers, Rob.

 

[Rob Nicholson]

All requirements points towards a WinForms app, the users have .NET FW and

WinXP, and with ClickOnce the major technical argument (deployment) for
WebForms falls short.

What goes around, comes around. Heck - we run Citrix Terminal Services on
the desktop here which is a real bizarre way of tacking TCO and centralised
computer At least if we have to install a patch, we only have to install
it one three "PCs" and it's instantly available to all 100 users.

Cheers, Rob

 

[mortb]

There *must* be some middle ground. Ignoring "web apps are easier to
develop" (they're not), the other issues have to be tackled which is access,
compatability and support costs (zero footprint).

When I first read about Java applets, I thought a solution was in the
offering. It still might be as opinion about the feasibility of large
complex web applications is questioned. The idea of walking up to any PC,
logging in as myself and small applets starting to download across the
Internet seems feasible to me. For example, a new PC has almost no software
installed. I hit the Word icon and enough Java code is downloaded to display
the toolbars etc. Start typing and the code to spell check is downloaded in
the background. Open a file and that's opened from the Internet and then
cached locally for speed.

The problem with my dream is that in practise is really hard to break down
that application yourself into Java applets. It would be far better if the
operating system/language did that behind the scenes - maybe the entire
application is 50MB big but the O/S doesn't load the whole lot - it just
pulls down the bits it needs over a slow link, maybe even as individual
methods are executed.

I've also felt this way about Java/applets since it came in the mid 90's.
Applets aren't happening because they have no real support from microsoft.
There is the .Net way and the J-way and they aren't completely compatible.
But applets are still written and maybe there will be a "silent revolution".

Windows has become the "mainframe phenomenon" of the decade -- too much time
and money spent developing for it so we can't quit using it.

I guess microsoft as well are waiting to see what's around the corner.
The bits and pieces for a new better concept for applications seems to be
there.
Someone just have to put them together good enough and get enough people
hooked.

/mortb

 

[Martin Rosén-Lidholm]

Perhaps WinForms + ClickOnce could be the low TCO solution in a not too
distant future given your requirements?

// Martin

 

[Rob Nicholson]

I've also felt this way about Java/applets since it came in the mid 90's.

Applets aren't happening because they have no real support from microsoft.
There is the .Net way and the J-way and they aren't completely compatible.
But applets are still written and maybe there will be a "silent

revolution".

Maybe, maybe

Windows has become the "mainframe phenomenon" of the decade -- too much time
and money spent developing for it so we can't quit using it.

A very difficult trap to climb out of.

Someone just have to put them together good enough and get enough people
hooked.

Ahh, easy to talk!

Cheers, Rob.

 

[Rob Nicholson]

Perhaps WinForms + ClickOnce could be the low TCO solution in a not too

distant future given your requirements?

We can hope .NET apps are easier to install anyway.

Cheers, Rob.

 

[Buzzby]

Perhaps you should look at the other deployment models you have
available with .net?

If you need the responsiveness and richness of a Winform GUI with
substantial back-ends, look at Zero Deployment winforms options aor
embedding the UI in a custom UserControl as an <OBJECT> on the web page.

Then you have the range of WebServices or remoting for talking to the
back-ends. The responsiveness of remoting is surprisingly good.

Hop this spurs the debate!

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!