5 ms·

I don't think it takes 3-4 times longer to do something in a web app versus a WinForms app. It all depends on what you are doing of course. Simple grids and dat

I don't think it takes 3-4 times longer to do something in a web app versus a WinForms app. It all depends on what you are doing of course. Simple grids and data entry type input stuff is simple to do in web apps.

jmcqk6 13y ago
I'm mainly a web developer, so I'm biased towards that stance, but I've had to work on LoB programs in web (mvc), winforms, and wpf. Winforms was the worse. I hope I never have to work with one again. WPF was a lot better than winforms. But it still couldn't compare with the simplicity of the web. It could have been because I was trying to write a WPF app that acted like the web app. WPF can be nice, and it's definitely nicer than winforms, but web apps are so incredibly simple that I really don't see an advantage. Especially when you consider deployment issues (WPF you need to keep deployments synchronized etc. Web app => single deployment and done).
- venomsnake 13y ago
  My experience is exactly the opposite - winforms were a joy to use, and I barely had any success with WPF. But I had a lot of experience with MFC which were extremely close to winforms.
  - Spearchucker 13y ago
    Agreed. I do a lot of graph visualization and find the immediate rendering model of GDI a lot easier to work with. Also, WinForms is an object-oriented UI, which just makes more sense in my head than the XAML/document/delayed rendering model. But this is just my personal preference.
  - Pxtl 13y ago
    Imho, WinForms had a lot of nasty bugs and counterintuitive messes - the databinding thing was clumsy, and the tabular data control has a lot of warts. But still, there was a lot to like in the simplicity of OOP Widgets.
    - ygra 13y ago
      At least there was databinding and it worked (more or less; but binding a complete database row to a window was easy and worked well – having to hand-hold the framework in where to put values and how to write them back is quite painful in comparison).
pjmlp 13y ago
The problem is then when your customer requires support for an endless list of browser versions each one with its own set of quirks. I jumped into web development with both feets back in 2000, nowadays I jump of joy every time we get to do a native application.
Iftheshoefits 13y ago
> Simple grids and data entry type input stuff is simple to do in web apps. Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I mean, if all you're talking about is "input number/text into box, press 'Save'" then sure, that's "simple." I don't think I've ever witnessed a business web app with such trivial requirements, though. After they've been through the "me, too!" (e.g., for "visibility", people will insist on the inclusion of feature X, even if it's not really necessary) and political/gossip/clique infighting grinders most such apps have ridiculous requirements that blow the complexity way up.
- Silhouette 13y ago
  Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I think the biggest lesson we've learned from the rise of web apps is that most business applications are simple. They come down to some sort of database, some sort of guided processes for using it, and some sort of structured user interface for data entry and reporting. These systems are inherently centralised anyway because of the shared data store that they are built on, so running the whole thing centrally and using dumb(ish) clients is a natural fit. This doesn't mean that all business software is suitable for running as a web app. If you're creating material rather than merely entering data -- writing a report, drawing a diagram, anything like that -- web apps are still many years behind native applications in what they can do. The more significant the creation, the more this effect takes over: when was the last time you saw a professional architect or engineer doing their CAD and rendering work in a web app, or a programmer working on a million lines of code in Google IDE? But it turns out that a lot of what people do with computers is more about simple data entry and then information consumption, and you don't need all the downsides of native applications for that. In a way, Microsoft and the like decided their own fate, because they made deployment and maintenance of native applications so onerous. If they'd had a standardised and robust deployment/upgrade facility for third party software on Windows years ago, including good support for centralised management by IT departments in the professional levels of Windows used by organisations, we might have had a different picture today. If they'd also maintained the focus they used to have on trying to provide backward compatibility at almost any cost, and developed new technologies incrementally rather than making big announcement where you just assumed their new thing would be dead in 3-5 years, I'm pretty sure they'd still be a leading business in the software industry. But they didn't, so the Web and the iPad came along, and now Microsoft are just trying to keep up.

jmcqk6 13y ago

I'm mainly a web developer, so I'm biased towards that stance, but I've had to work on LoB programs in web (mvc), winforms, and wpf. Winforms was the worse. I hope I never have to work with one again. WPF was a lot better than winforms. But it still couldn't compare with the simplicity of the web. It could have been because I was trying to write a WPF app that acted like the web app. WPF can be nice, and it's definitely nicer than winforms, but web apps are so incredibly simple that I really don't see an advantage. Especially when you consider deployment issues (WPF you need to keep deployments synchronized etc. Web app => single deployment and done).

venomsnake 13y ago
My experience is exactly the opposite - winforms were a joy to use, and I barely had any success with WPF. But I had a lot of experience with MFC which were extremely close to winforms.
- Spearchucker 13y ago
  Agreed. I do a lot of graph visualization and find the immediate rendering model of GDI a lot easier to work with. Also, WinForms is an object-oriented UI, which just makes more sense in my head than the XAML/document/delayed rendering model. But this is just my personal preference.
- Pxtl 13y ago
  Imho, WinForms had a lot of nasty bugs and counterintuitive messes - the databinding thing was clumsy, and the tabular data control has a lot of warts. But still, there was a lot to like in the simplicity of OOP Widgets.
  - ygra 13y ago
    At least there was databinding and it worked (more or less; but binding a complete database row to a window was easy and worked well – having to hand-hold the framework in where to put values and how to write them back is quite painful in comparison).

pjmlp 13y ago

The problem is then when your customer requires support for an endless list of browser versions each one with its own set of quirks. I jumped into web development with both feets back in 2000, nowadays I jump of joy every time we get to do a native application.

Iftheshoefits 13y ago

> Simple grids and data entry type input stuff is simple to do in web apps. Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I mean, if all you're talking about is "input number/text into box, press 'Save'" then sure, that's "simple." I don't think I've ever witnessed a business web app with such trivial requirements, though. After they've been through the "me, too!" (e.g., for "visibility", people will insist on the inclusion of feature X, even if it's not really necessary) and political/gossip/clique infighting grinders most such apps have ridiculous requirements that blow the complexity way up.

Silhouette 13y ago
Well, for an appropriately narrow and trivial sense of "simple" I'd agree. I think the biggest lesson we've learned from the rise of web apps is that most business applications are simple. They come down to some sort of database, some sort of guided processes for using it, and some sort of structured user interface for data entry and reporting. These systems are inherently centralised anyway because of the shared data store that they are built on, so running the whole thing centrally and using dumb(ish) clients is a natural fit. This doesn't mean that all business software is suitable for running as a web app. If you're creating material rather than merely entering data -- writing a report, drawing a diagram, anything like that -- web apps are still many years behind native applications in what they can do. The more significant the creation, the more this effect takes over: when was the last time you saw a professional architect or engineer doing their CAD and rendering work in a web app, or a programmer working on a million lines of code in Google IDE? But it turns out that a lot of what people do with computers is more about simple data entry and then information consumption, and you don't need all the downsides of native applications for that. In a way, Microsoft and the like decided their own fate, because they made deployment and maintenance of native applications so onerous. If they'd had a standardised and robust deployment/upgrade facility for third party software on Windows years ago, including good support for centralised management by IT departments in the professional levels of Windows used by organisations, we might have had a different picture today. If they'd also maintained the focus they used to have on trying to provide backward compatibility at almost any cost, and developed new technologies incrementally rather than making big announcement where you just assumed their new thing would be dead in 3-5 years, I'm pretty sure they'd still be a leading business in the software industry. But they didn't, so the Web and the iPad came along, and now Microsoft are just trying to keep up.