4 ms·
First, thank you for your service. You did an excellent job, really. WinForms is on my resume, and I'm proud to have it there. I love it, and consider it the go
by BuckRogers 8y ago
First, thank you for your service. You did an excellent job, really. WinForms is on my resume, and I'm proud to have it there. I love it, and consider it the gold standard for GUI development. I'm not the only one with this opinion.[0]
WPF just came at the wrong time, as mobile was about to ascend and added complexity (which I'll admit can definitely add to correctness). Given hindsight, they should've just extended WinForms in some way. Leaving more complex needs than whatever that extension entailed to the Win32 API. UWP is fine and would be the greenfield target, but being Windows 10-only makes it a nonstarter at any enterprise I've worked at. So it's WPF/UWP that are essentially dead to me. Once Windows 7 is completely abandoned, I'll change my tune and stop promoting WinForms and go with UWP. But not today.
I'm all about building out on WinForms, or while not a UI framework, Blazor. The latter of which is part of an application/UI rewrite that we're looking to do for a WinForms app that I maintain, once it hits 1.0.
WinForms does the job and it allows me to almost entirely focus on the business logic.
[0]https://sietch.net/ViewNewsItem.aspx?NewsItemID=271 https://sietch.net/ViewNewsItem.aspx?NewsItemID=271
- tigershark 8y agoCompletely disagree after years and years working on winforms and wpf and switching between them at my current job. You can really tell the difference when using Wpf, you can see that it was created years later and with testability in mind. Trying to test a winforms app is much more painful and even for debugging you need continuously to switch between code behind, controller, child controllers. In a properly architected wpf app you have no code behind. And good luck with laying out your components manually, without the designer it’s a massive pain compared to xaml. So kudos to the gp and to all the great guys the worked on winforms, but please don’t tell me that they shouldn’t have introduced wpf.
- shawnb576 8y agoI think you're both right. Winforms was built on the Win32 stack, which is pretty basic and doesn't allow you to cleanly separate concerns. We had to build layout, hwnd recreation for style changes, clean wrappers around multi-hwnd objects (damn you combobox), etc. Some of these concepts around MV*, TDD, etc weren't that well known in 1998-2000. WPF was designed to merge the best of client with what was happening on the web at that time. Data binding, declarative layout, model-view separation, these are all much better BUT you're also left dealing with styling, transitions, other stuff. WPF is clearly more powerful (I also worked on Silverlight fwiw), but takes more skill to operate. We were targeting the VB6 user who was creating LOB apps at a big enterprise and wanted to get things done and move on.
- BuckRogers 8y agoI had already covered most of his point when I noted that the complexity can contribute to correctness, so it came off very emotional. I actually would stand by the view that WPF should've never been created, and WinForms extended. I've never heard a compelling argument to change my mind. Instead, I'd rather have seen a path that led to just WinForms and UWP today. If you read the link that I provided, the author feels the same. WPF is the most pointless of all three. If you want XAML, there is UWP and it's more useful, and has a better future. It's hard to imagine much of a future at times for even UWP with Electron's popularity and HTML/CSS web interfaces. It's clear that Microsoft is gearing up for massive Electron optimization with their adoption of Chromium, so that's going to just accelerate as those apps run better and use less battery while doing it. For me, native GUI might just die with WinForms. I'd hate to see it go, it's always going to remain ideal for internal tools.