Winforms compared to ASP.NET

25 Comments

• Robert...you teasing minx :-)
  

• Too bad we have to wait until 2005... The application I'm working on is due in two weeks! ;-)
  

• Exactly my point. It's not that WinForms are bad, and perhaps I was severe in saying that they suck, it's just that WinForms are not as approacheable as webforms. Maybe they will never be equal, but it should be easier.
  

• Probably depends on your background, I work with a guy who is from a pure VB / Winforms background...he gets on with Winforms MUCH better than I do...
  

• Incidnetally...Fabrice...that cursor is cool and all...but an 'off' switch would be nice :-)
  

• There's a pretty cool framework available at:
  
  
  
  www.oakleafsd.com
  
  
  
  You can download the developers guide for a good overview of how to program for winforms and webforms...
  
  
  
  
  
  [Mere Mortals .NET 1.0 -- 2 years of tapping .NET's strengths and working around its pitfalls went into our Mere Mortals .NET Framework. MM .NET is written in C# and continues our tradition of developer tools that make it easy to follow best practices. This Framework is a must see for developers building applications using C#, VB .NET, or managed C++ and wanting to utilize the full-power of Microsoft's .NET Framework. Bringing .NET to Mere Mortals!]
  
  

• Ok Scott, I'll just remove it. It was fun for a while... ;-)
  

• Not saying remove it...it really is nice...just after a bit of scotch (10 year olf Macallan...very nice) it become a bit swimmy :-)
  

• If you've developed windows based apps before instead of web apps, WinForms wouldn't be so hard to understand. For a good comparison, pick up Petzold's Programming Windows and compare that to Sells' WinForms book. You'll see that WinForms is MUCH easier than trying to code windows in C.
  

• I shouldn't have put such a strong tease in there. Avalon won't replace WinForms. I was just being a bit of a smartass. But, it'll be interesting to see what people say after the PDC.
  

• "I'd like to drop a note to the windows forms team"
  
  
  
  -- We're all ears, and eager to hear your opinions. I am a developer on the Windows Forms team, and I also write a lot of ASP.Net in my spare time. Are they different? You bet! Is this bad? Sometimes, but not usually. You don't want them to be too much the same -- imagine having to do the equivalent of a postback in a client app just to update the UI of a clock, or imagine doing a postback in a web app for each movement of the mouse.
  
  When we were working on both win and web forms we communicated a lot. The main goal was to make the programming API similar (both have Text properties, for example, and both use roughly the same names for common controls). But, we did not want to force either model down an avenue that wasn't natural. Windows Forms is about the client, and for better or worse, it's built on top of Win32 and relies on opaque rectangular windows to do its bidding. Web forms has a much more flexible rendering technolgy via HTML and CSS, but a much less flexible way of interacting (postback, limited script).
  
  I do agree that Microsoft needs to do a much better job at showing folks how to mix the best of these two models. Really, we're still figuring it out ourselves.
  
  

• "I think it's good, we need this. But you have to help us, bring winforms and webforms closer!"
  
  That's not possible with the current tool that is used to render webgui's: HTML. HTML sux big time when it comes to gui's.
  

• Frans, what I mean is that the logic behind the components should be closer. Brian says they tried to make the controls similar (same properties...), but some more work needs to be done.
  
  Maybe I'm blinded by the DataGrid controls, which are very different... BTW, I don't really get the way the winform DataGrid works. It just feels strange to me to work with a grid (table) without Rows or Cols properties.
  

• My problem with WinForms is not that the API is substantially different from WebForms - I don't think API convergence between those platforms should necessarily be a goal. My concern is that WinForms doesn't provide a rich enough toolbox for developing a modern looking Windows application. Build a WinForm app with the stock WinForm controls and what do you get? A rather pathetic, circa-1994-looking app. There's a certain basic level of UI sophistication that's expected these days...image menus, rebars/coolbars, docking, wizards, etc. That kind of stuff really needs to be available out-of-the box with the framework. As it is, you basically have to use some third party library (whether it be free code from CodeProject or a commercial third party control library) to make a decent looking app.
  
  
  
  I really like the potential of smart clients, especially with no-touch deployment apps combined with web services. I can definitely see the pendulum swinging back away from web apps for a lot of applications. But that's hampered by the fact that it's easier to make a decent look webforms app than a decent looking winforms today.
  

• I agree totally; 1994 is about the year I'd peg for an app written in Windows Forms today. If you're using .NET 1.1 it's a little better because we have some support for XP themes (but not much). You'll see some great things in this department from our upcoming release. I can't really say more until the PDC, but it should be possible to write something the caliber of Outlook 2003 right out of the box without resorting to a ton of custom code.
  
  Unfortunately, while I think we'll handily get you a look and feel that's up to 2003/2004 standards, you still won't have the flexibilty of the web via CSS. That, actually, is something we've thought about but we haven't devoted enough resources to make it happen.
  

• Brian, Since we got your ear: Could it be possible that MS make some windows/office 2003 icons redistributables with VS.NET? It is pretty hard to copy them :)
  

• I think this is in progress, but I'll pass it along just in case. Thanks!
  

• Brian,
  
  
  
  That's great news. I haven't heard much around WinForms in Whidbey thus far - I'm heartened to hear that some real energy was put there. Unfortunately, I won't be able to make the PDC (rotten timing), but I'm sure PDCBloggers will keep me up to date. And I'm hoping I'll be able to get a hold of the PDC bits somehow, even if we can't attend (MSDN universal, maybe).
  

• another word: Flash
  

• Let's hope MS does not bet everything on Avalon and Longhorn, because it would mean we'd have to wait until 2008 to build applications with that technology. 2008 because not everyone will be running Longhorn as soon as it is out! And we'll have to write applications for XP for a while.
  
  Hopefully we'll see improvements in between...
  

• Brian,
  
  
  
  CSS or CSS-like support for winform controls would be a huge improvement.
  

• Brian, this is planned for Longhorn with Avalon and XAML.
  

• I would love to see something like the MSHFlexGrid for windows forms. Much better capabilities for presenting information than with the ListView or DataGrid.
  
  Ability to wrap text and set the row heights and cell properties independantly.
  
  Overloading the paint event for the DataGrid must impact resources? Are additional column styles the solution?
  
  Will the new ListGrid (name correct?) planned be available as a control before Longhorn.
  
  Third party controls are an issue in a new and evolving platform.
  

• Hi, I'm new in this forum so hello to everybody.
  
  Everyone is talking about Rich UI, deployment, etc. But could someone tell me about speed? Imagine 1000 people accesing the same form and doing changes in the DB. I deducted that WinForms would be faster than WebForms but exactly I haven't deducted why.
  

• Vic, I'm not sure how you came to that conclusion. Maybe you're trying to compare connected mode to disconnected mode? Winforms can also be used in disconnected mode, so the difference between Webforms and Winforms regarding load and performance is reducing. Unless you have computations you could move to the client computer, in which case Winforms are better adapted.