VS is probably the only reason that WPF is being touched at all.
Eventually, they'll say that VS is dead and VSCode is the new VS, then we'll be off WPF and win32 ties, it'll also put to bed the "Why is VS not 64bit yet?" line of inquiry.
Eventually, they'll say that VS is dead and VSCode is the new VS, then we'll be off WPF and win32 ties, it'll also put to bed the "Why is VS not 64bit yet?" line of inquiry.
I'm guessing that with the Longhorn disaster WPF lost whatever resources it was going to get to make it really kick ass.
If your goal is to write .NET (C#, F#, VB.NET, what have you), ReactXP doesn't help. UWP XAML is the answer people seem to be looking for but for whatever reason keep missing it as the successor to WPF.
If you are already using patterns like MVVM, databinding, service models, and keeping business logic separated from UI/UX logic, the transition should be mostly seamless from what I've seen outside of a few XAML tweaks (which are primarily fiddly details like namespace changes).
In the case of more complicated migrations, you can now use the Desktop Bridge: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop...
For line-of-business apps it's DOA because ADO.NET is not available. Custom widgets (e.g. for industrial control) are much harder to develop because there's no replacement for GDI. The list goes on. UWP is, and was intended to be, only a platform for "apps" which act as a frontend for externally hosted web-services - not "real software".
What we should be campaigning for is for the XAML "Jupiter" platform within UWP to be made fully available in the pure Win32 world, with no special runtime, sandbox, or artificial restrictions.
- It wasn't a good idea even in WPF to use an hWnd directly
- There is a full file browser available to UWP apps since Windows 10
- The application design guidelines are much less prescriptive since Windows 10
- There's nothing saying you can't use a tree view, just a warning that most users don't like tree views and tree views are typically not very accessible (to users with disabilities, to users that prefer touch controls, to users that hate navigating useless hierarchies)
- DirectX has been the suggested replacement for GDI since WPF launched, UWP just enforces it; UWP XAML even has more and better ways to composite DirectX and XAML layers together
- That stated, System.Drawing is higher level than just GDI, and is missing today. This is also an issue faced by .NET Core in general. There are open source System.Drawing replacements available today. .NET Core should have one more directly in .NET Standard 2.0/.NET Core 2.0 soon (and UWP once .NET Native pulls that in)
- The "desktop bridge" allows full Win32 processes to bundled with an application
- The full jungle of ADO.NET is an issue, but it's the same issue being faced across all of .NET Core: it's expected to get better with .NET Standard 2.0/.NET Core 2.0 soon and the .NET Native that pulls that in
- Even "real software" needs sandboxes for security and reliability. That was the complaint with UAC in Vista; that's the same complaint here. Exactly like with UAC the UWP sandbox started (back in the "WinRT days" in Windows 8) from a position of strength and is slowly working to strike a balance for "real software" to run but also be secure and easy to install/uninstall
From a lot of the .NET side of complaints, the "artificial restrictions" are primarily the transition to .NET Core. Yes, it's a sometimes painful transition for legacy WPF applications, but it's a lot better than the WPF/Silverlight transition and it's a transition that will continue to get better as .NET Core grows. A lot of the complaints about .NET Core in general are going to go away with .NET Standard 2.0/.NET Core 2.0, which will converge a lot more of the "classic .NET Framework" into/on top of .NET Core.