Printable View
Hi all,
I noticed that more are now converting applications into WebForms rather than using WinForms. Since both can be invoked within IE, then why do most still prefer WebForms?
Although I would have to admit the WinForms requires .Net Framework installed on the machine.
Just wanted to get some insights on this.
Thanks.
You may have put your finger on it: the Framework. Isn't this one of the things that prompted the development of SilverLight?
I don't think there is any one answer; WinForms and WebForms are used for two different things. You usually don't run into projects where it's a good idea to build it in one or the other; usually the application's purpose and target audience decide for you.
They can be 'invoked' in IE, but it's not the same thing. With ClickOnce, you end up downloading a thin client to your machine. With web forms, you don't download anything, just view it like any other web page. There's the appeal - easier distribution, instant access, all that.
thanks all for the info. it's just that i read a thread in the microsoft forum that microsoft will eventually stop support for WinForms which i think is sad. since i'm more of a WinForms developer.
i was trying to look for that thread so i can share it you guys but i can't seem to find it.
just hope that wasn't true.
That won't be true. It can't be; there is a need for desktop applications and the web supports them poorly. It will never happen. If anything, I wouldn't be surprised if more native solutions replace what the web currently is within a few decades.
From my point of view if I can write a WebForms app I will choose that over anything else its easier to deploy control and update. Obviously webforms cant do as much as win forms as far as functionality. But I can serve a webforms app to a budget PC so from a business point of view web forms will win.
Pino
Personally I much prefer developing and using desktop applications over web apps... I dont think there is any truth in microsoft getting rid of winforms, at least not for a very long time.
No there not going away, the web cant handle everything a webform can do. (Yet!) however from a business point of I dont think there is any question. Webforms are just .. well cheeper.
Pino
I highly disagree. While ASP.Net / WebForms cut down on rollout costs to multiple users you need to factor in much more. The company I'm currently with has determined that ASP.Net costs quite a bit more to develop than WinForms applications and recently made a decision to write our CMS in WinForms (and I've got to say we've made much more progress in the WinForm arena even though this is typically a WebForm shop).Quote:
Originally Posted by Pino
With ASP.Net you have to worry about too many things. For one, every server request objects are created then destroyed. This makes processing things a bit more difficult as instead of having an object in a WinForms to track everything, you have to constantly reload that object from Session, viewstate or wherever else you are storing it. ASP.Net requires changing your thinking and doing a bit of extra work. Events are not as useful (such as the On Text Change event; insanely useless in ASP.Net unless you're using AJAX). Not to mention that the web is stateless and JavaScript is slow (something the ASP.Net framework heavily relies on).
You also have to worry about how different browsers display your web application. Even IE6 versus IE7 can create huge differences so even if it's entirely internal it can still be a PITA.
We have two large projects here; 1 WebForms and 1 WinForms. I cannot tell you how much time as been wasted trying to optimize / lose ViewState, get authentication working across multiple sub pages (every component is a separate web application), WorkFlow for logins, events within DataGrids on server controls and other things. All of these issues were resolved but the time we wasted working towards this we could have had a solution built in WinForms much faster; however WinForms for our current WebForms project would be inappropriate seeing that it's a website and all. My point being is due to the applications being a web site, we had quite a bit of extra work because of the different type of environment.
On the contrast we have a WinForms project that operates as a CMS for our WebForms project and it's amazing how much faster we were able to get a really workable solution up and running. On top of that it even looks good :cool:. It's not as if our WinForms project is smaller than our WebForms; it's roughly the same size in complexity.
The bottom line is: there is quite a bit of extra thinking that needs to go into an ASP.Net application that isn't necessary on the WinForms side. This means a shorter development time for WinForms. I'm not saying WinForms are always appropriate; my original post stated that it depends on the target audience and what the application does.
I totally agree, I was going to say something similar but thought it was just cos I have not done a lot of work with ASP.NET that I found everything to be much more of a pain... but obviously even experienced web developers face these problems too.
Yes, web development has allways been like this. However its not un-workable.Quote:
You also have to worry about how different browsers display your web application. Even IE6 versus IE7 can create huge differences so even if it's entirely internal it can still be a PITA.
The problems your company seem to have encountered based on your post are training/skills issues not to do with the technology.Quote:
The bottom line is: there is quite a bit of extra thinking that needs to go into an ASP.Net application that isn't necessary on the WinForms side. This means a shorter development time for WinForms. I'm not saying WinForms are always appropriate; my original post stated that it depends on the target audience and what the application does.
Pino
Obviously it's not un-workable but the fact of the matter is that it extends development and design time. We've obviously gotten around all of these areas but that doesn't mean WebForms take less time; they don't.Quote:
Originally Posted by Pino
Wow.. that's incredibly rude (that or you're just ignoring my points, contorting them to fit your idea, and responding like I'm some sort of half-wit). I didn't realize you actually knew who everyone was, what their still sets are, etc. Also, you keep saying WebForm everytime you mean WebForm or WinForm; stop that.Quote:
Originally Posted by Pino
So, explain to me how we lack appropriate training just because we've had some ViewState bloat (almost every commercial ASP.Net application I see has quite a bit; seems like no one cares to clean it up like we did). Or because we found out that handling row commands in a GridView in server controls (remember, server controls are not user controls) is a PITA (I should really say I found out; this was one of my items). Also, what does training have to do with useless ASP.Net events or general browser slowness with executing JavaScript?
I never said we were not capable of doing any of these things nor did I say we couldn't do them or we had difficulty doing them. Regardless of whether you're the king of ASP.Net or not, these things take extra development time that WinForms do not need to account for.
You seem to be confusing what exactly we're talking about. WinForms take less time to develop due to many less steps you have to take. This does not mean that ASP.Net is too hard or anything remotely like that.
My above post was not in any way rude of offensive. If it came accross that way then I appoligise. I'm in the middle of a million things and can see why my pspot appears short.
If you have 2000-5000 Pc's to deploy an application too, an application which you know is going to grow and continue to grow then I've never seen a WinForm solution selected. I've seen the talks I've been in the meetings and never has a WinForms application won.
I'm trying to share my views and experiance just like you are. I'm not wanting to offend or start a flame war.
Note: I've also update my previous post as the last line was a duplicate I was thinking of the best way to write it.
Also some good points mentioned below,
http://social.msdn.microsoft.com/For...-f86aa2857929/
This is perfectly understandable and why I think that most choices between WebForms and WinForms are pretty easy as they're highly dependent on your audience, content and purpose.Quote:
Originally Posted by Pino
Regardless of purpose, however; I still think WinForms take less time than WebForms to develop. But, as I mentioned before (and as you point out), it's not always feasible with large deployments.
Yea, I'm kinda with you on it really my mind is side-tracked these days by money and costs. I do prefer developing Windows Apps!Quote:
Originally Posted by Kasracer
Right tool for the right job comes to mind!
Webforms - Short term pain for long term gain.
Winforms - Short term gain for long term pain.
Web development is tougher, there are many factors to deal with, loose standards, proprietary topics, browser wars, end users, etc. but after you overcome the pain of it, it's worth it.
Of course, with the right precautions and knowledge and experience, both webforms and winforms can be made easier.
one thing i don't quite understand...
if having 2000-5000 pc for deployment, isn't it almost the same with webforms and winforms.
i know the on webforms it's as easy as viewing a webpage.
in winforms, isn't it the same as viewing a webpage with an adobe flash activeX or silverlight? since you need to download them in order to run the page properly. although i would say that the .Net Framework is a bit large compared to Silverlight or Adobe Flash Player but what i'm pointing out is there's still the need to download something and this is only one time download too.
any thoughts?
There really is no such thing as a one-time download, whether you're talking about the .Fat framework, Flash runtimes, etc. Users get steadily pestered about updating these things and have to pay the price if for no other reasons than security patches.
I'm still confused about what everyone is arguing over though. Are you talking about the incredibly clunky beast known as an Ajaxy Web application, a web-delivered applet (Flash, Silverlight, even WinForms), or a real desktop application? Are these what are being contrasted or is the discussion limited to Web content and leaving out real applications?
We are discussing WebForms (Ie .aspx websites) and WinForms (windows desktop applications)
Pino
I have... that's what I'm working on now... a desktop app that's going to replace a web-based app - and a DOS based app - in fact it's actually a suite of several apps that work integrated with each other. It's deployed to a web server on the company's site via Click Once... the users will have to login to the network, navigate to the correct page, click the app.... if a new version is available, it downloads and installs. If not (or once install is done), the app launches. As for the frameworks, well, that's what logon scripts and system standards are for. System-wide, as far as I know, FW3.5 has been deployed everywhere it needs to be.Quote:
Originally Posted by Pino
In my opinion that's the problem of the network infrastructure folks... at least here where I am, they've got it down pretty good. All updates are held until they can be tested on multiple systems. Only after they've been tested do they get releast to the rest of us. Sometimes it comes in the form of a Windows Update, sometimes it's deployed via login scripts. What ever it takes. All server updates are handled by hand and in groups. Dev and Test first... then Integration, then Production. Client systems are scattered all over the place.Quote:
Originally Posted by dilettante
I think the discussion is based on decisions being "do we go with a web-based app, or a desktop app?"Quote:
Originally Posted by dilettante
As for the previous comment about MS eventually dropping WinForms support.... heah, it'll probably happen at some point... once WPF has started to take off. I think what you'll find is WPF replaces WinForms AND WebForms.... you'll finally have a single consistent base for both thin and thick clients.
-tg
Here in Italy, more and more companies are switching from Internet shared applications to INTRANET shared ones and, as you know, the Intranet allows you to share desktop applications. Creating a LAN is no longer a prerogative of large companies today. Consequently, it still makes sense for a programmer to devote his time and effort to native software. There are so many different browsers around today -- each one having its own restrictions -- that developing universally compatible Web based software has become an enormous headache.
Well that helps clarify things a lot for me.
The decision of whether to create a Web application or create a desktop or client/server application is pretty complex. I don't think there is any single approach that fits every case.
I suppose "WinForms" might go away in .Net someday, and the replacement might be WPF or whatever replaces WPF. The "WebForms" browser-based UI won't replace it entirely though until .Net completes its retreat to the server though, as Java did 10 years ago. Just as with Java you'll see the occasional contrarian using a "widget framework" to try to make desktop applications in .Net. This will be seen as eccentric however, and rare.
Long live COM and native code! ;)
how about performance wise? which one provides better performance? also in security.. which approach is more secured? or are these on a case to case basis?
Performance and security are important. But sometimes you need reach. That is something a web application has that is hard to beat.
Sometimes you gain security by isolating as much logic as possible at the back end. Keeping logic near the database can seriously enhance performance too by moving as few bits over the long wire to and from the client as possible. But a fat client can be quite interactive and responsive, another sort of performance to consider.
My point is you can argue the architecture all over the place until you have a specific problem to solve. There is no single answer.
I prefer a win client application over web client application in general. Win client uses local machines processing power rather than the server's. This means that having a fast server with large memory is not mandatory.
Simplest of computers today are quite powerful. Rather than taking advantage of this power on the client, web forms depend on the processing power of the server.
With Win client application could be designed in such a way that client machines do what they are supposed to do and server machine does what servers are supposed to do.
With win client one may not need very high speed internet connection. Win clients can give much better performance with slow data connections. With win clients, bandwidth is used only to send and receive data rather than UI information. Hence more users can use same bandwidth using Win client, when it would become mandatory for Web client application to increase the server bandwidth.
Win clients can take advantage of local hardware.
From developers point of view: To develop a web client you need to know several technologies like HTML, CSS, JavaScript, {ASP.Net/JSP/PHP etc.} AJAX, XML, JQUery etc. where as, Win clients could be created using single programming language. Code is much more readable in win client application. Win client applications could be designed much more quickly.
Win clients had only one disadvantage over web client. That was distribution. With advent of technologies like "click once" and open source technologies like "zero install" this problem is also greatly solved.
Another practical issue with win client was regarding storing database connection strings on the client machine was not considered safe. This problem can be solved easily. Win client or web client should not make database calls directly. They should make calls to a service layer. Service layer could be a hosted via webservice, remoting, java rmi or wcf service on the server. DB connection info must be saved with the service layer, this will keep database safe and also all the data requests will become even safer.
In one of my projects "Server" and "Client Launcher" applications are distributed via "click once". Actual client that is compatible with the server is distributed with server itself. Client launcher and Server both are always up to date as they are distributed with click once. Client launcher interfaces with the server and queries the Win client version compatible with the server. If compatible version exists in the client launchers sub directory then client launcher runs the client otherwise it requests the compatible client in zip format from the server, unzips it in new directory and then launches the client and also passes the server url to it.
Another thing that many web client supporters promote is that the web client is platform independent. Web client can be browsed from any computer or mobile phone browser.
Well, I'll say it true. But I personally do not prefer using my business software from phone. Firstly, because keys on the phone are too small. Chances of entering incorrect data through mobile phone are much greater then using a pc.
However, I would not mind using a tablet pc for my enterprise application. But soon tablet pcs will come installed with desktop class operating systems this means that we'll be able to use win clients on tablets too.
Having my enterprise application interfaced through web browser has another risk as well. It will be opened to even most novice attackers 24 X 7. Lets say, what if my business rival opens my web application through his web browser and tries to guess user name, password several times a day. A new employee I hired forgets to change his default password or changes it to a very simple one or a guessable one. Web client is a boon for malicious attackers. Where as if I am using a Win client, it will become really very difficult to guess what application I am using in the first place, where it is hosted, where is the server, what database etc.
For small businesses one can host server specific modules on the fastest machine on the network and win clients could be installed on the not so fast machines. This way small business owner does not needs to buy a powerful server machine. Small business owner can buy third party hosting to host it's server modules(eg. weservice layer) and database and use win client to connect to it from every where. Since UI is not being transfered to client on every request it will save bandwidth and hosting costs for small business owner.
Web clients too have their own place. Web clients are good candidates for web stores, blogs, e-mail, social networking etc Most of these Web apps also have a fast Win client option as well. In short web clients must be used for application which are very general in nature and have large number of casual users/visitors.
Conclusions, I have refrained from using many applications because they do not have fast win client interface where as I am still using few legacy application just because they have very fast and responsive UI. I use outlook / outlook express although my e-mail service provider has web interface.
congrats... dredging up a 2.5 year old thread to write a dissertation that next to no one will read... kudos...
and riddled with mythconceptions too...
-tg