2 ms·
I 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 layo
by shawnb576 8y ago
I 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.