React Native for Windows is helping Settings improve more quickly
microsoft.github.io
microsoft.github.io
> 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.
(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.
https://github.com/microsoft/react-native-windows/projects/3...
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.
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.
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.
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.
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.
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 "????").
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 is 20 years old already, it appeared in .NET Framework 1.0
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.
If you restrict yourself to the most recent decade I can agree.
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.
[1] hidden at the bottom of https://blogs.windows.com/windows-insider/2022/02/16/announc...
> 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.
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).
An even safer rule of thumb is to only install LTSB/LTSC builds of Windows, if you can get access to them.
Windows isn’t good all the way through.
- parts from win8
- parts from win7
- parts from something that resembled winXP
- some obscure settings that felt unchanged since win2k
That was it for me, never logged into Windows since, don't know if it got better or worse.
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.
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.
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.
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.
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.)
MS using tools like this, instead of supporting (like linux on Azure), is selling the message
"Our tools are not that good".
This lack of confidence is telling, and I think, part of the Balkanization of all myriads of UI kits on windows.
MS, Apple, nix are not just APIs: Them are the biggest UI kits vendors! So, when I use Apple, I also "buying" the UIs and UIs toolsets.
Apple is the only that stay firm with the idea that their UI is first, and MUST be best (misteps, yes, but still...).
MS in the past was like that.
It show with VB and the unified UI kits (or at least, more unified). Their APIs were balkanized, but the UX experience was one.
Now even it succumbs to glorified electron apps. Its a reflection of who is building it almost, there is just no passion for craft anymore.
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.
.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.
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.
Thanks!
But anyone can tell you that RMW apps won't be as performant as a native app, such as a WinUI app.
Apple has dropped the ball on UIs
Though, I guess the previous N iterations of Settings will still be available behind hidden menus, right?
Windows is an abomination.
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.
"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.
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.