I think you miss the more common reasoning though. This starts with "can we build a Windows app?" The answer to that was "no" for many more people until relatively recently. The .NET Framework wasn't as available by default until the second half of the 2000s which caused some Windows app devs to hold off beyond the performance reasons and WinForms vs WPF. Electron and React go hand-in-hand here as they made a (crappy) Windows app easy.
What I feel popularized this was the webview approach on mobile. In 2010, there were a ton of frameworks popping up for hybrid mobile development. This was carried forward to desktop although some of us had been embedding IE webviews much earlier. This let people say "yes" and it went from one thing to the next with diversions into React Native.
I ditched Windows long ago so I'm mentioning this only in the interest of accuracy.
"Infecting with screwdrivers" now see how dumb that sounds?
So no, React is a (poor) solution, not the problem. The problem is Windows can't nail down a solid SDK for it's platforms.
As a user, however, I find that the Start menu has become more sluggish than it used to be, and that's pretty annoying. What about that?
lol what a weird response.
So React, the most popular front-end library and used my hundreds of thousands of successful apps, is the ridiculous electric screwdriver? See how weird that sounds and makes it obvious you guys can't give an honest assessment?
Pretty much everything in there still works, if I type it in and compile it with the current Visual C/C++ toolchain. I might need to get rid of a few MOVEABLE and DISCARDABLE tags here and there, I suppose.
Idk, and I'm not saying it's not a good question, but it's irrelevant to the comparison in OP's comment.
which on one hand, good -- fuck microsoft and the monolith; on the other hand we get react start menus when we have to use microsoft.
What's the issue?
Other apps are successful despite being slow and bloated, since performance isn’t a primary concern of users. In contrast it’s critical for OS internals like the start menu, so a javascript runtime and framework is just the wrong tool for the job.
React only makes sense as a layer on top of the browser DOM, because the DOM itself cannot be fixed without rewriting it from scratch, so making it usable for non-trivial UI needs to happen in the 'framework layer'.
But without the DOM as the thing that needs fixing and the restrictions of the single-threaded browser-event-loop, the React programming model simply doesn't make a lot of sense. Using the "React-paradigm" outside the browser (e.g. SwiftUI, React Native) is pure cargo-culting, it only makes sense for onboarding web-devs who are already familar with React - but makes it harder to create UIs for anybody else.
The actual problem in the context of Win11 is of course that Microsoft doesn't have any sort of longterm strategy for Windows system APIs (not just UI frameworks). The only long-term-stable API is Win32.
React is the symptom here, not the cause.