4 ms·

> That has always been Microsoft strategy: offer lot of different tools and options for people to create applications. React native for windows is just another

> That has always been Microsoft strategy: offer lot of different tools and options for people to create applications. React native for windows is just another option Microsoft developed. And it's a bad strategy, given the state of a lot of these UI frameworks developed by windows. Instead of committing sincerely to something, you're not even getting started with a framework it's already deprecated. I understand companies that stuck with Winforms for 2+ decades, since the rest is an unfinished buggy mess. Remember WPF? Yes, me neither... Here is a better strategy, just let people code their winform/XAML/... UI in Javascript or Typescript directly like with Jscript.net in the past.

dgellow 5y ago
To be fair WPF is still well supported and used widely. It won’t be deprecated any time soon.
- deleted 5y ago
  [deleted]
- pas 5y ago
  But is it getting the maintenance necessary to be future-proof? Is it getting the updates/features/documentation/care first or is there some new better-loved more recommended, hyped solution?
  - dgellow 5y ago
    I don't think anyone knows, not even Microsoft!
  - electroly 5y ago
    The answer for awhile was definitely no, but now it's yes. They have re-committed to both WinForms and WPF. I would suggest that, when it comes to Microsoft technology, you don't want the hyped solution. You want the boring stable solution. Following Windows trends is a path straight to development hell. If you wanted something new and exciting you'd be writing a web app in the first place.
    - minimouse 5y ago
      What do you mean by "now"? Did something happen this month? WPF and WinForms haven't seen much at all for... a long time. This comment sums it up well: https://news.ycombinator.com/item?id=29424984 https://news.ycombinator.com/item?id=29424984
      - electroly 5y ago
        .NET 6 was released last month. This is the first release when you can reasonably use Windows Forms and WPF with .NET Core; they've spent a few years getting those frameworks to that point. I'm not sure that addresses what the other commenter is talking about, though. In this thread we were talking about "maintenance" and "future-proofing" but that commenter is talking about major new features; I'm not sure that we're talking about the same things.
  - WorldMaker 5y ago
    With a lot of the "WinRT walls" torn down and WinUI controls available "out of the box" in WPF today (.NET 5+), WPF is almost a best of both worlds providing both the access to "better-loved more recommended" solutions and having a somewhat contiguous path back to a strong legacy of older code (modulo what you think of the .NET Framework 4.x to .NET 5+ hump; it's not quite a "just rebuild and it'll work", but it's also not as bad as some developers imagine it would be). At this point, right now if you are looking to build a Windows 11-targeted WinUI "green field" project the current green path (and almost the only currently supported path) is to start with a WPF application in .NET 6 and pull in WinUI controls.
electroly 5y ago
WPF is still kicking. The big difference between the UI frameworks is who developed them. WinForms and WPF came from DevDiv, so they will be supported forever and are stable choices. UWP and WinRT came from the Windows team; I'd put money on them being passing fads. React Native came from outside of Microsoft entirely, so it's probably a safe choice too.
WorldMaker 5y ago
Bad strategy or not, it's a working strategy across nearly a half-century. "Bring your favorite language to DOS [later Windows]" got a lot of developers building for DOS and then Windows. It also keeps entire industries afloat as legacy code written in boutique languages survives pretty much intact across many versions of Windows. Not having to rewrite software every half-decade because Apple changed their mind on preferred programming language or preferred CPU architecture has left Windows with a lot of enterprise/industrial users that would never consider using anything but Windows because they don't want to budget for that. To some uses, Windows having a diverse mishmash of UI frameworks from multiple decades/eras/epochs all living side by side and mostly interoperating without challenge is a massive feature rather than a bug. Sure it's ugly, but it's stable.
- throw_m239339 5y ago
  > it's a working strategy across nearly a half-century. I don't believe it's working, at all, when all these teams end up building GUI with Elektron (ironically owned by Microsoft now). It means that developers have very little confidence in all these MSFT technologies.
  - WorldMaker 5y ago
    Nah, it just means that Electron is the new Java is new VB6 is the new FoxPro is the new Pascal is the new… Every era of computing has had its "frowned upon" tools for building software that were productive to a class of developer that needed to get stuff done and couldn't "afford" the "right" tools. Electron kind of proves the strategy is still working more than it proves the strategy is not working. Windows itself doesn't care if you build a UI in Win32 or Electron or XAML or Tcl/Tk or DirectX or bubble gum and duct tape for that matter. That's the strategy: let developers do what they want (for the most part). That's still working as a strategy even if you as a user don't like Electron, or you as a user hate that Electron apps don't look like Win32 apps don't look like XAML apps. "Consistent designs" isn't working, but "software written in late 1990 something in VB6 against Win32 still works in 2022" is a working strategy. As a developer, you have choices, even if that choice is to use Electron or to use VB6 to build apps in 2022 despite the VB6 IDE itself not running or supported in any Windows after Windows XP (the runtime is still supported for eternity, but development tools are stuck).

dgellow 5y ago

To be fair WPF is still well supported and used widely. It won’t be deprecated any time soon.

deleted 5y ago
[deleted]
pas 5y ago
But is it getting the maintenance necessary to be future-proof? Is it getting the updates/features/documentation/care first or is there some new better-loved more recommended, hyped solution?
- dgellow 5y ago
  I don't think anyone knows, not even Microsoft!
- electroly 5y ago
  The answer for awhile was definitely no, but now it's yes. They have re-committed to both WinForms and WPF. I would suggest that, when it comes to Microsoft technology, you don't want the hyped solution. You want the boring stable solution. Following Windows trends is a path straight to development hell. If you wanted something new and exciting you'd be writing a web app in the first place.
  - minimouse 5y ago
    What do you mean by "now"? Did something happen this month? WPF and WinForms haven't seen much at all for... a long time. This comment sums it up well: https://news.ycombinator.com/item?id=29424984 https://news.ycombinator.com/item?id=29424984
    - electroly 5y ago
      .NET 6 was released last month. This is the first release when you can reasonably use Windows Forms and WPF with .NET Core; they've spent a few years getting those frameworks to that point. I'm not sure that addresses what the other commenter is talking about, though. In this thread we were talking about "maintenance" and "future-proofing" but that commenter is talking about major new features; I'm not sure that we're talking about the same things.
- WorldMaker 5y ago
  With a lot of the "WinRT walls" torn down and WinUI controls available "out of the box" in WPF today (.NET 5+), WPF is almost a best of both worlds providing both the access to "better-loved more recommended" solutions and having a somewhat contiguous path back to a strong legacy of older code (modulo what you think of the .NET Framework 4.x to .NET 5+ hump; it's not quite a "just rebuild and it'll work", but it's also not as bad as some developers imagine it would be). At this point, right now if you are looking to build a Windows 11-targeted WinUI "green field" project the current green path (and almost the only currently supported path) is to start with a WPF application in .NET 6 and pull in WinUI controls.

electroly 5y ago

WPF is still kicking. The big difference between the UI frameworks is who developed them. WinForms and WPF came from DevDiv, so they will be supported forever and are stable choices. UWP and WinRT came from the Windows team; I'd put money on them being passing fads. React Native came from outside of Microsoft entirely, so it's probably a safe choice too.

WorldMaker 5y ago

Bad strategy or not, it's a working strategy across nearly a half-century. "Bring your favorite language to DOS [later Windows]" got a lot of developers building for DOS and then Windows. It also keeps entire industries afloat as legacy code written in boutique languages survives pretty much intact across many versions of Windows. Not having to rewrite software every half-decade because Apple changed their mind on preferred programming language or preferred CPU architecture has left Windows with a lot of enterprise/industrial users that would never consider using anything but Windows because they don't want to budget for that. To some uses, Windows having a diverse mishmash of UI frameworks from multiple decades/eras/epochs all living side by side and mostly interoperating without challenge is a massive feature rather than a bug. Sure it's ugly, but it's stable.

throw_m239339 5y ago
> it's a working strategy across nearly a half-century. I don't believe it's working, at all, when all these teams end up building GUI with Elektron (ironically owned by Microsoft now). It means that developers have very little confidence in all these MSFT technologies.
- WorldMaker 5y ago
  Nah, it just means that Electron is the new Java is new VB6 is the new FoxPro is the new Pascal is the new… Every era of computing has had its "frowned upon" tools for building software that were productive to a class of developer that needed to get stuff done and couldn't "afford" the "right" tools. Electron kind of proves the strategy is still working more than it proves the strategy is not working. Windows itself doesn't care if you build a UI in Win32 or Electron or XAML or Tcl/Tk or DirectX or bubble gum and duct tape for that matter. That's the strategy: let developers do what they want (for the most part). That's still working as a strategy even if you as a user don't like Electron, or you as a user hate that Electron apps don't look like Win32 apps don't look like XAML apps. "Consistent designs" isn't working, but "software written in late 1990 something in VB6 against Win32 still works in 2022" is a working strategy. As a developer, you have choices, even if that choice is to use Electron or to use VB6 to build apps in 2022 despite the VB6 IDE itself not running or supported in any Windows after Windows XP (the runtime is still supported for eternity, but development tools are stuck).