Hacker News Reader

Comment by jeroenhd | Hacker News Reader

To me, this is telling about the current state of native Windows development. When even Microsoft can't be bothered to use their own app framework and instead chooses to rely on a "cross platform" code base, I don't see why anyone would pick Microsoft's toolset over existing solutions such as React Native.

View on HN

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.

As a result you never know what to bet on and spend way too much time evaluating different technologies. And there is very little coherence between applications. That seems to work for them but as a dev it’s really frustrating to never feel there is a clear direction moving forward.

If they actually start using their own tools that’s already an improvement compared to let’s say, Blazor. React native for windows is also used by the XBox application in windows.

> 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.

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

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?

I don't think anyone knows, not even Microsoft!

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.

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

.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.

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.

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.

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.

> 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.

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).

The fact that Microsoft has produced all these half baked UI frameworks that rapidly go unmaintained is a demonstration that this "strategy" isn't one at first place. MSFT doesn't know what they are doing.

The ones I mentioned? What are you talking about? More than half of them were never built by Microsoft in the first place (including Electron).

For the most part in its history Windows has officially only ever had 3 UI frameworks: Win16, Win32, and WinRT (or WinUI if you prefer to call it that). Win16 was shut down in the 32-bit transition (but had a compatibility path that lasted for many years following the transition). Win32 has a lot of individual "sub-frameworks" based on the decade the software was written in, but overall is still "maintained", but "stable". WinRT has had some hurdles with branding/naming/messaging/developer support, but that is in part because is very actively maintained and still growing and in part because Win32 is still maintained and legacy code developers don't want Microsoft to forget it/leave it behind, worsened by Microsoft taking too long to nail down a transition more like Win16 to Win32 in "soft" forward compatibility and relatively known end date (end of 16-bit processor support). They've put a lot of work in the "soft" forward compatibility in recent years, though partly in detriment to the "relatively known end date" (in Windows 8-10 it was "as more things move to mobile, HoloLens, Xbox" and in Windows 11 it is now "????").

> Microsoft ... you never know what to bet on

For 20+ years! https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New!

>now ADO.NET

Now ?!!! ADO.NET is 20 years old already, it appeared in .NET Framework 1.0

This is a quote from a 2002 article.

> That has always been Microsoft strategy [...] > And there is very little coherence between applications.

I don't think that's an accurate statement, at least it felt a lot more cohesive back in the Windows 3.x to Windows 2000 days.

Sure you could write your applications in different languages, but they had one API for doing GUI, and they had lots of documentation on how applications should behave. As a result applications felt very cohesive overall.

Interestingly it was Microsoft who really started to go against their own guidance with Office. Suddenly a toolbar which was not part of the standard GUI API, which didn't look like anything native. And they've continued to push this trend, resulting in the current mess.

I mean... you're talking about something more than 20 years old. I don't think that goes against my general statement :)

Sure, but first version of Windows came out 37 years ago...

If you restrict yourself to the most recent decade I can agree.

In fairness, Microsoft are the main developers of React Native for Windows and Mac. I'm kinda hoping they continue down this path and make it an officially supported framework.

I'm viewing that this is an effort (not probably appealing to the HN crowd) to gather developer interest and make desktop apps make sense again. This is probably Microsoft eating their dogfood on their critical components rather relying on a cross platform code base. (FYI, the whole React Native for Desktop thing was started and is being pushed by Microsoft.)

I wish they just added utf8 support for the win32 api and called it a day.

https://docs.microsoft.com/en-us/windows/apps/design/globali... ?

Hah, nice. I missed that.

React Native is built on the native app framework of each platform (which is currently WinUI2/UWP on Windows, supposed to be moving to WinUI3/WinAppSDK in the future)

https://github.com/microsoft/react-native-windows/projects/3...

Already moved to C++/WinRT and WinUI3! The Win11 Settings page featured in this article clearly uses some WinUI 3 components and the link towards the bottom is to an article on the C++/WinRT "turbo" bindings support available in React Native for some time now.

There is of course not any one “Microsoft,” rather thousands of individual programmers on hundreds of teams, all making decisions.

If you are building cross platform app, there isn't much reasons to lock yourself in into platform specific framework, but just look at new Windows Terminal, it's great and it is using WinUI 3.

It is very slow and does more draw calls than a modern video game, melting laptop batteries:

https://www.youtube.com/watch?v=hxM8QmyZXtg

Same guy from this video did a series of videos rewriting the renderer in a weekend or so and going hundreds or thousands of times faster, with more advanced unicode/ligature/language support.

The text drawing code isn't using WinUI tho, they embed terminal canvas into something called "islands", so in this case it's not an UI frameworks fault. Besides I have used it on relatively old laptop and it was fine for me, but others experiences might differ.

Reply on news.ycombinator.com