I think managers were promoted for infecting their features with Copilot, and developers for infecting them with React, and here we are.
OneDrive managers on the other hand are one step away from inventing some way of adding a gacha mechanic.
back
4 comments
It is worth pointing out that it is the Recommended section in the menu that uses React Native. See also https://devblogs.microsoft.com/react-native/rnw-settings-win...
I ditched Windows long ago so I'm mentioning this only in the interest of accuracy.
Infecting with React can be easily explained by pathetic state of desktop application development environment.
This is an interesting point when the question is "how do I build a Windows app?" and a decision needs to be made. React is definitely one of the options that some consider when this question arises.
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.
Blaming React is absurd. Its like blaming the screwdriver instead of the person using it.
I too would absolutely blame a plumber for trying to fix my leaking pipes with a screwdriver instead of e.g. a solder patch. Not everything is a screw, not even in the developing world.
lol Blame the plumber then.
"Infecting with screwdrivers" now see how dumb that sounds?
Blaming React is correct. It is like asking for a picture on a wall and instead getting noisy, power hungry plasma TV on a wall.
I recently began developing an app for Xbox Series X/S. The only framework that will work is UWP. When you look at the UWP docs, this is at the top of the page highlighted "If you are starting to develop Windows apps, we recommend you consider using the Windows App SDK, and WinUI rather than UWP. Although still supported, UWP is not under active development. Please see Start developing Windows apps for more information."
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.
Or instead of React you can use native WinUI. So using React is just lazy bloatware introduction
This metaphor is so stupidly bad it's hard to believe you guys even know what React is.
I'm not a dev and actually don't know what React is. I don't care for this metaphor.
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?
Thank you, your comment sure helps to improve our understanding of React a lot.
We can blame both. If my repair bill was higher because the mechanic chose to use a ridiculous electric screwdriver that used tons of power to achieve what a normal screwdriver can and stripped the screws in the process then I'd also be upset with both the mechanic and the ridiculously inefficient tool.
> a ridiculous electric screwdriver
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?
React is a javascript library. Javascript needs its own runtime. Why not just write stuff in native windows controls and save having to run an entire javascript runtime for no reason?
> Why not just write stuff in native windows controls and save having to run an entire JavaScript runtime for no reason?
Idk, and I'm not saying it's not a good question, but it's irrelevant to the comparison in OP's comment.
Using an entire javascript runtime and framework to make your OS start menu is using a ridiculous overpowered electric screwdriver that strips heads. Using native windows controls is using a proper manual screwdriver that just works
it's also just a numbers thing. react and more broadly JS developers are a dime-a-dozen as far as availability goes compared to winapi folks.
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.
Only someone who has not tried to write stuff in "native windows" would ask this question. If you want a real answer, go try and develop a Windows native application real quick. I'll wait...
I would hope that the windows developers who are working on the windows shell would know how to write a windows native application in C. If it's that bad, they should improve the API, not just write it all in react instead
Windows 7 was not written in react, it looked great and worked great.
Get those guys to write the UI for Windows 11.
What parts of Windows was written in React?
I learned Win32 programming from the Petzold book circa 1993.
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.
This is such a ridiculous argument. Applications were developed long before JavaScript was a thing.
.NET Framework needs its own runtime. Java needs its own runtime.
What's the issue?
I have no issue with user-facing applications doing whatever they want, electron apps bundle an entire chromium to do their thing, but there's a win32 and win64 api in C for a reason, to make OS level stuff fast
I wouldn't want my start menu to load the entire Java runtime before opening, that's the issue at hand.
Its popularity or success in other apps has nothing to with the windows situation.
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.
"Shit tastes great! Millions of flies can't be wrong!" ;)
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.
He isn't blaming React (or Copilot), but those who used them in context they had no place in.
"developers with infecting then with React" is 100% blaming React
No it’s directly putting the blame on developers
"I'm on HN and whenever I see React mentioned I'm constitutionally incapable of not saying something dumb"
Seen in the context of the thread, with the both of you never addressing the actual problem at hand but instead reflexively and vigorously defending React against an alleged attack, I'm sorry to say this reads like an admission.
Nobody's blaming React. The blame lies on the bad developers that chose it to write a freaking start menu.
React is the symptom here, not the cause.
What does "infecting them with React" mean?
Introducing bloat.
Umm sir, it's Windows. Bloat is part of its core architecture.
Fair point...
So you’re saying that the people (HR) team is responsible and that their retention and growth policies are to blame.