> React Native for Windows is helping Settings improve more quickly
From near the start of the article:
> In this blog post, we discuss how and why Microsoft is using React Native for Windows to deliver the Your Microsoft Account page in Windows 11 Settings.
This isn’t the entire Settings app, but rather one specific page that used to only be available online, but now they want it available in the Settings app too:
> Enabling you to manage your account information directly from the Windows 11 Settings is one of the key goals for the new Your Microsoft Account page. Before Windows 11, your only option for managing these settings was to visit the account.microsoft.com website (“AMC”). The team wanted to have a consistent set of functionality and user experience between the native and web versions and considered several options to accomplish this […]
The reasoning behind their choosing React Native does not apply for anything else in the Settings app in any way, so I don’t think you can expect to see anything else using React Native any time soon.
This is true, but it allows them to test the waters. If it is successful, it further opens the door to web-style programming on windows. And as MS keeps switching their UI story, having react to force them on an externally dictated standard might finally mean, well, a default UI default framework on windows again. Something we've been missing since Win32 ruled the earth.
Going from the oldest UI elements Win11 currently has, IIRC it something from Win2k, all the way up to React Native, Windows is becoming a living museum of UI.
It is hard, but Microsoft has the workforce and knowledge to do it. Yet they are not comitted to it, one reason being compatibility. There are businesses today relying on 10+ year old custom solutions developed for XP.
This React Native work is using the same "default UI framework" from Windows 8 (WinUI/WinRT, whatever you want to call it), the big thing that has shifted was Windows 8 did JS bindings directly inside IE11 and "Spartan" Edge and now the preferred tool seems to React Native when working with JS (or TS).
(Which in some ways is actually a regression from the Windows 8 approach because the IE11/"Spartan" Edge-backed plan supported WinRT bindings and WinUI user interfaces "progressively" in PWAs: rather than recompiling your JS for React Native with its own React Native "skin" there was a more direct path to "upgrade" a regular web-hosted app and boring "old fashioned" HTML DOM to WinRT/WinUI. Somewhat ironically, too, the WinUI name even came from these earlier Windows 8 efforts, but WinUI.js died as Microsoft decoupled WinRT bindings from IE11/"Spartan" Edge and never got a "3.0".)
I think the narrative that Microsoft keeps switching their UI story is more about the confusion of the shifting bindings than actually about the stack as whole. The stack is relatively consistent over time, just things like .NET versions kept changing (and where .NET fits with respect to the application hosting model/lifecycle) and JS saw this regression from being a "first class" supported binding with a path for PWAs to it's finally back in React Native (and currently only React Native), and even is starting to feel "first class" again, if you don't mind React Native now as the only way forward.
The XBox dashboard and Office are other examples of React Native creeping in, and I edited the subject because the title isn't clear about the blog contents.
Xbox and Office are irrelevant here. You editorialised the title, from something that was accurate and sufficiently clear to something that’s factually inaccurate and wildly misleading. (It isn’t Settings but a small part, it isn’t a rewrite but of new functionality, and the “improve more quickly” the title mentioned is crucial to the purpose of the article, which is explaining why they chose React Native for this piece—this being a React Native for Windows blog post, not a Windows blog post.) If you still can, please revert the title to the original.
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.
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.
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 "????").
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?
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.
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.
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.
> 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.
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.)
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)
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.
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.
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.
In related news, since Windows 11 Insider Preview Build 22557, installing with Microsoft account is mandatory[1]. If you preferred local account, well, you know how Microsoft respects your preferences.
> Similar to Windows 11 Home edition, Windows 11 Pro edition now requires internet connectivity during the initial device setup (OOBE) only. If you choose to setup device for personal use, MSA will be required for setup as well. You can expect Microsoft Account to be required in subsequent WIP flights.
Ugh... why do you have to do this to us Microsoft?
I log into a Microsoft account anyway, but I always make it local first because signing in with my Microsoft account during setup would always name my user folder as my first name but missing the last letter (I don't understand why.. my name is only 6 letters long).
I simply created a throwaway account during installation. However, I ended up using a fake birth date that was under 18 yo. So later I ended up having to create _another_ fake account with the age of an adult to allow me to create a local account with admin priviledges...
I stopped using the LTSC branch because it doesn't have seamless upgrades between versions. I discovered that some of the main programs I was using (like Windows Terminal) refused to run on older versions of Windows LTSC, but didn't want to reinstall the whole OS just to use these programs.
So I read the article and I understand the reason why they wanted to use React Native for this specific part of the application. At the same time, I can't help but wonder about their priorities when they are rewriting parts of the new app while there are still configuration options in Windows which require you to go to the old Control Panel.
Even the context menu in File Explorer has two entirely different styles in Windows 11 — the old style along with all the third party items you need hidden behind a “Show more options”. UI consistency simply isn’t something they care about, the OS accumulates new inconsistencies with every release.
I'm glad that Microsoft agrees with Linus on: "Don't break userspace"
The Apple way might have been to take away those old Config Panels with no replacement for years, or ever. Or breaking third-party File Explorer extensions and forcing devs to rewrite them.
Many of us are blaming that on designers that use macOS as their daily drivers and are paying too much attention to Apple's bad examples. We can criticize Windows 11 for doing it wrong in one area (the Taskbar) and also support them for trying to do it right in another (making sure that the new context menu lives side-by-side the older one to not break older workflows and extensions that may never have a chance to update).
I wonder if Windows or its UI will ever get a ground up rework considering how scared newer developers must be to touch the underlying legacy code base. That would probably require breaking backwards compatibility at some level and that doesn't look a principle MS is keen on abandoning. Windows 10X and RT both got abandoned. But on the other hand they can't keep piling stuff on top without fixing the core forever right? The context menu hack is already an example of the cracks beginning to show in this approach.
> UI consistency simply isn’t something they care about
While this is somewhat true (especially from Win8 onwards), one of the reasons you have "old-style" menu as a submenu is completely different: it is to make less calls to ContextMenuHandlers, used exactly for "all the third party items". It was a great addition in Win95. By the time of WinXP it was a source of many problems, but of course it was shitty Windows being shitty and not a 3rd party app problem.
It would be less jarring and defensible if the main menu and old-style submenu didn't have different font sizes, line heights (as a multiple of font size), icon sizes, margins, hover transitions, highlight colors, ctrl behaviors, etc.
In its own way, "these Settings you can only get to by opening a web browser and going to account.microsoft.com" is just as bad as "these Settings you can only get to by finding them in an older Control Panel", isn't it?
Even assuming it is "zero sum" that this Settings page took resources away from other Settings migrations, it's still a net win for "Settings all in one place" isn't it? (In which the article also points out is unlikely to be a "zero sum" case here, because the whole point of using React Native is so that the team that is in charge of "account.microsoft.com" directly can own the Settings page and can share code in it with what they also run on account.microsoft.com. It seems highly unlikely that that web-based team has any other older Control Panel they "own", and more likely that if they own their own Settings page that a team that does own older Control Panels and new Settings pages doesn't have to "moonlight" or "hand hold" the web team's Settings work.)
The days when every new Windows feature came with a snazzy UI to configure it are long gone.
Realistically, Server 2012R2 was the last release that had full parity between features and matching configuration 'screens'.
Since that time (so: Server 2016, 2019 and 2022, and to a lesser extent the consumer SKUs), configuring new features has required PowerShell and/or WMI. This trend is unlikely to reverse anytime soon. Mostly because features are increasingly complicated.
With Windows 10 and, especially, 11, the GUI parts of the configuration have been redone on a "whatever looks good and is usable for 80% of non-advanced users" basis.
That this now requires "web" technologies is disappointing, but unsurprising. There just isn't a good "native GUI" story right now: not in the open source world, but especially not with Windows or macOS.
> configuring new features has required PowerShell
Which it should.
Window should be PowerShell-first, and GUI eventually. Even more, GUI should use PowerShell so that you can configure stuff via GUI and export the script for automation. This then leaves to anybody to create GUI if they want, and GUI is just a PowerShell frontend.
It's still like that in Windows 10, there are menus that look like they date from Windows 95/98 ( device manager comes to mind), and there's the new Settings thing ( the one where you can only have a single instance of it).
Windows 10 control panel/settings app is FUBAR. In some versions, tasks as simple as change ip address etc. became mission impossible. There are two sets of UI, neither is working...
A few years ago Windows 10 still had a Windows 3.11 file picker deep in the control panel databases stuff (ODBC, &c.), I think it was. It’s probably still there.
Adding printer drivers manually with the "Have Disk..." option still brings up a dialog box with an icon of a floppy disk that defaults to a path of A:\.
Well, they have telemetry, they see where users go most often. They probably see what users tried to use but haven't completed. Maybe they even can correlate that with support requests.
For some reason I have mixed feelings about this. I appreciate the React paradigm for UI development. It simplifies and facilitates a lot of complex interactions. However, being based on RN, it means a JS Interpreter is running in the background. Compared to native compiled binaries JS uses much more RAM. I would like the core OS applications to be written in the most efficient manner as possible. But I guess very few programmers want to manually manage memory these days.
Declarative UI doesn’t have to be inefficient. SwiftUI is fast and IMO nicer to use than React. There are a few declarative UI frameworks in Rust as well (Druid is very nice).
I dunno, Office is C++ and yet moving Office 2016 _windows_ around is comically slow and nukes the CPU from orbit. Microsoft - anyone really - has no issues at all writing slow, garbage UIs in any language or framework.
Yeah, this never worked well in windows (I remember switching 'show window content while moving' to 'off' whenever 'on' became the default).
Taskbar 'autohide' is still a clusterfuck (I don't remember a version of Windows, where this feature didn't have at least visual bugs). New centered taskbar in Windows 11 is just bad usability (only smart thing about start button was, that it was in a corner of a screen thereby making it easy to hit with a rough mouse movement).
Oh well M$! Would you please stop massing around by breaking existing functionalities and provide something really works? The core utilities such as diskpart etc. used to be rock solid, now there are quite a few subtle but really annoying bugs. In some versions of Windows 10, network settings UI in both traditional control panel and the new settings UI are both broken, it took me quite a few reboots to finally making it right. And now, seems they are trying to introduce a 3rd stream. Maybe it's going to be SNAFU.
Those aren't really the settings they're talking about. Whoever submitted this to HN messed up while editorializing the title.
They're talking about the settings associated with your "Microsoft account". Since it's a web "service", there is of course a web page from which you can manage that account. But they wanted to (also) let you do it from within the Windows control panel. That page of the control panel -- and only that page -- has been implemented in React Native.
Obviously this doesn't involve "rewriting" anything, since this is something that didn't previously exist.
I don't understand. Just please make a good UI toolkit for your desktop OS and stick to it. Wasn't the point of the new settings app to use UWP/XAML?
.NET MAUI is Xamarin Forms with a new name so devs don't get whiplash, UWP is falling apart slowly and apparently now being abandoned by MS themselves, so I guess I'm supposed to use their new built-in edge webview for all of my desktop UI now? I don't want to make my desktop apps in javascript, WASM is too slow to be useful, everything else is a hack.
This Settings page is still using UWP/XAML though these days the more accurate term is probably WinUI3 XAML. It isn't using a WebView at all. It is using JS as the programming language responding to/driving the UI, but it's still "native controls" (in so much as such a concept ever really has any meaning).
Currently not a Windows user, but I'm interested in developing applications for major desktop operating systems.
I wonder how React Native program performs when compared to the native one. Specifically, how many memory & CPU does a React Native program consume compare to a native one with the same functionality?
The blog didn't provide the information, but it did mentioned that "... performance and accessibility of WebView UX tend not to be as good as a native equivalent". I'm just curious.
The Xbox app is not a good indication of RNW performance, by the way. It's like what Slack or Teams is to Electron. According to Microsoft, they don't have any external clients yet. Nor any internal clients apart from Xbox, and now Windows. That means there is no VS Code of RNW just yet.
But anyone can tell you that RMW apps won't be as performant as a native app, such as a WinUI app.
For all the criticisms Microsoft is getting for this, why don’t we criticize Apple as much for embedding web views in iOS Settings app (and now macOS System Preferences!), namely the subscriptions page and anything to do with iCloud settings. Basically every time I can drag an image out of what it should be a native dialog or god forbid get a downscaled version of the image that is not optimized for Retina.
I don't want to sound negative, that's all nice and good, but since it's about the "Microsoft" (=online) and not Windows (=local) account (although I think they try to blur the line pushing the former in all possible ways), it shouldn't matter what language it's written in - it could be just web page embedded in any widget. And from this point of view, it makes sense to use a web-related framework - not because of it being cross-platform (kind of, I believe only Windows and macOS are supported, for Linux you need something like Proton).
Three hard resets yesterday because Chrome shat itself and Windows 11 (fresh unused installation) would not allow me to just kill it, and eventually froze itself too. Retarded and pathetic. Too bad I need to use this garbage from time to time...
An 'abomination' that over hundreds of millions of users are using everyday vs a microscopic fraction of that being used by virtually no-one but bots on the internet - which is Linux on the Desktop (also which 'Linux' distro).
Everyone knows Windows 11 is the best Linux Distro these days.
I can't even fathom what is microsoft even thinking, what are they even trying to accomplish by introducing a new so-called hipster thing every 2-3 years. Till today the setting apps doesn't have all the thing that we use to get from Control Panel easily. And, due to their backward compatibility windows ui development has become hodgepodge of uwp, react native, win32 forms, wfp etc.. Thankfully, Linux and Apple are heading to correct direction.
God I miss Metro UI. What happened the that? Why did Microsoft chicken out on some actual good UI that took risks and elevated computing to a new level.
It was a nice tablet environment and also massively wasteful and inconvenient for the vast majority of people running laptops and desktops. It was dead-on-arrival and I predicted it would be dead-on-arrival since prerelease versions of Windows 8.
It was great on laptops and desktops. One person's "wasteful" is another's "clean, crisp, friendly". Large click targets are wonderful with a mouse, per Fitz's Law. Plenty of whitespace gives the eyes places to rest. Smart uses of whitespace give the eyes smarter flows. Many of the Metro design guidelines were "old best practices" from magazines and newspapers. As our screens have scaled up to DPIs much more resembling print documents much more than CRTs and pixels the size of dimes that was a great idea ahead of its time. (And something Apple gets a lot less flack for in its "Retina" age design guidelines.)
"Metro" was never "dead on arrival" it was murdered by very vocal minorities of users and developers and subsequent over-corrections that could have been better solved with smaller tweaks.
> "Metro" was never "dead on arrival" it was murdered by very vocal minorities of users and developers and subsequent over-corrections that could have been better solved with smaller tweaks.
Sure, you can believe this, and I'm sure the good folk at Microsoft believed it too. They were wrong, and so were you :)
Metro not only messed up people's workflows by taking over the screen, it itself was massively inefficient for any kind of work due to low information density. The Microsoft Store was a cesspool of scamware because who the heck would develop exclusively for an unpopular platform beyond scammers trying to trick grandma. Good riddance.
My prediction is that within foreseeable future, ownership of general purpose computing machines will be illegal for the general public (on the usual arguments of terrorism and protecting the children).
So this is the nth reiteration of one part of a company trying to embed web-tiles into their native front-end to speed up development because the OS team are under-developed on front-end aspects.
Sony tried it on their store-front, as did Microsoft on their start-menu. Curious to what's changed now though to make this work?
* Have they solved the security nightmares that cross-domain iFrame call's became?
* Is performance and memory overhead just "good enough" now?
* How does theming (dark-mode ect) stay consistent?
* How does accessibility stay consistent between native->website->native (tabbing, narrator ect).
> An interpreted language being clue code for native widgets doesn't affect UI speed that much.
Did you ever try PHP + Gtk? I beg the differ. All interpreted languages aren't made equal. Furthermore, it's not just "glue code" when all your business logic has to be written in Javascript as well in a React Native app.
> Windows 11 settings rewritten in React Native
The article title:
> React Native for Windows is helping Settings improve more quickly
From near the start of the article:
> In this blog post, we discuss how and why Microsoft is using React Native for Windows to deliver the Your Microsoft Account page in Windows 11 Settings.
This isn’t the entire Settings app, but rather one specific page that used to only be available online, but now they want it available in the Settings app too:
> Enabling you to manage your account information directly from the Windows 11 Settings is one of the key goals for the new Your Microsoft Account page. Before Windows 11, your only option for managing these settings was to visit the account.microsoft.com website (“AMC”). The team wanted to have a consistent set of functionality and user experience between the native and web versions and considered several options to accomplish this […]
The reasoning behind their choosing React Native does not apply for anything else in the Settings app in any way, so I don’t think you can expect to see anything else using React Native any time soon.