4 ms·

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 wi

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.

MichaelGG 9y ago
VSCode isn't even remotely near VS. But WPF did get a lot of work once VS decided to use it. Up until then, WPF couldn't even render text without making it blurry - that's how little effort it had. I'm guessing that with the Longhorn disaster WPF lost whatever resources it was going to get to make it really kick ass.
- WorldMaker 9y ago
  The WinRT/UWP XAML stack is the return/revenge of the Longhorn XAML stack. It took a while to get here, but it is the present now.
  - zeroc8 9y ago
    Yeah, but now you can use ReactXP for that, just like the Skype team does. And it runs on UWP, Android, IOS and Web.
    - WorldMaker 9y ago
      ReactXP looks interesting, I will explore it some. 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.
      - maxxxxx 9y ago
        The problem with UWP is that there is no migration path from WPF. They are so different that you have to pretty much rewrite from scratch.
        WorldMaker 9y ago
        My experience is that there isn't as much to rewrite as most developers think. (But then I've had in the past to maintain Silverlight versions of WPF applications, so I'm biased.) 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-to-uwp-root https://docs.microsoft.com/en-us/windows/uwp/porting/desktop...
        maxxxxx 9y ago
        I tried to rewrite a WPF app when WinRT came up and it was hopeless. I'll admit I haven't looked at it again so maybe things have improved since then.
      - DaiPlusPlus 9y ago
        UWP is not the successor to WPF for a simple reason: it's sandboxed, and comes with a very prescriptive UX platform (no tree-view, hWnd, or FileOpenDialog here, folks!) 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.
        WorldMaker 9y ago
        You seem to be under several misconceptions. Yes, it's sandboxed by default, but that isn't the problem you seem to think it is. - 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.

MichaelGG 9y ago

VSCode isn't even remotely near VS. But WPF did get a lot of work once VS decided to use it. Up until then, WPF couldn't even render text without making it blurry - that's how little effort it had. I'm guessing that with the Longhorn disaster WPF lost whatever resources it was going to get to make it really kick ass.

WorldMaker 9y ago
The WinRT/UWP XAML stack is the return/revenge of the Longhorn XAML stack. It took a while to get here, but it is the present now.
- zeroc8 9y ago
  Yeah, but now you can use ReactXP for that, just like the Skype team does. And it runs on UWP, Android, IOS and Web.
  - WorldMaker 9y ago
    ReactXP looks interesting, I will explore it some. 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.
    - maxxxxx 9y ago
      The problem with UWP is that there is no migration path from WPF. They are so different that you have to pretty much rewrite from scratch.
      - WorldMaker 9y ago
        My experience is that there isn't as much to rewrite as most developers think. (But then I've had in the past to maintain Silverlight versions of WPF applications, so I'm biased.) 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-to-uwp-root https://docs.microsoft.com/en-us/windows/uwp/porting/desktop...
        maxxxxx 9y ago
        I tried to rewrite a WPF app when WinRT came up and it was hopeless. I'll admit I haven't looked at it again so maybe things have improved since then.
    - DaiPlusPlus 9y ago
      UWP is not the successor to WPF for a simple reason: it's sandboxed, and comes with a very prescriptive UX platform (no tree-view, hWnd, or FileOpenDialog here, folks!) 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.
      - WorldMaker 9y ago
        You seem to be under several misconceptions. Yes, it's sandboxed by default, but that isn't the problem you seem to think it is. - 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.