I would still say that means Windows Start uses React, frankly.
Ok
>This is the part of the Windows Start that uses React.
Ok
I could be wrong but I feel like when most HN commenters say that something "uses React" and also imply that that's a bad thing, what they really mean is "it loads a full web rendering engine and consumes ~200mb of unnecessary ram". Neither of those things are true here.
This is incorrect. It is a full JavaScript framework in your start menu.
I don't see your read that it's about ram-hungry web views either. To me, "Start menu uses React" is a dig that Microsoft is so uncommitted to it's native development platform that they (partially) don't use it in one of the most 'core' parts of the operating system.
If it fits and meets the goals of the project, why not?
If you know why it was chosen and if it was a bad choice compared to other frameworks, please do tell.
I don't have any inside information; I'm running with the hypothetical.
To some extent, yes. But if they choose React Native, something's probably wrong, because (despite what the article says) that requires throwing in a Javascript engine, significantly bloating a core Windows component. If they only use it for a small section ("that can be disabled", or in other words is on by default), it seems like an even poorer trade-off, as most users suffer the pain but the devs are making minimal advantage of whatever benefits it provides.
If the developers are correct that this is the best choice, that reflects poorly on the quality of Microsoft's core native development platforms, as madeofpalk said.
If the developers of a core Windows component are incorrect about the best choice, that reflects poorly on this team, and I might be inclined to say no, someone more senior should be making the choice.
But we'll always hear "it's React!". Like most things, the masses must feed on the Internet outrage without critical thought.
I mean, with tons of effort and config Windows can be turned into a usable OS. Needing to do all that is a huge part of the problem.
>No, Windows Start isn’t built on React. No part of the start menu actually uses React.
But then
>This is the Windows 11 start menu. See that Recommended section at the bottom of it? That is built with React Native for Windows.
Its not just the headline its the content of the article.
What it should have done is focused on this claim:
>Microsoft is also vowing to use its native Windows UI framework, WinUI, in more areas of the system
Because like they said, React Native is calling WinUI.
But trying to split the React/Native hair is honestly just tiring. Its like saying you dont drink Coke, and then downing a full glass of Coke zero. "Oh but what I meant is that it doesn't call any sugar dependencies at all" is just weird. Just say you don't drink Sugar.
Is the recommendations panel in the start menu, which nobody actually wants to begin with, really so complicated that it justifies bringing in a JS runtime?
And is C# and WinUI really so hard to use that they can’t just make it with that?
And if WinUI is hard to use, maybe they should like.. make it better?
At least Apple had the decency to take the React paradigm and turn it into a native part of their development platform with SwiftUI, even if the implementation has been a bit rough around the edges.
>So that’s it. Windows Start has a very small section (that can be disabled) that’s written in a framework that follows React principles and compiles down to native code.
False. React Native doesn't "compile down to native code". It runs actual JavaScript, just not inside a browser, but a standalone JS runtime.
> This was an oversimplification bordering on being misleading. It’s a lighter JS runtime that’s calling native code for rendering controls. The argument still has merit. Just because something in JS doesn’t make it slow or bloated. Interpreted languages will almost always be slower than their native compiled counterparts, but it’s negligble [sic] for these purposes.
Isn't it a full JS runtime? I think by "a lighter JS runtime that's calling native code" you mean it doesn't deal with HTML/CSS rendering, but that's not what JS runtime means. These are separate parts of the browser architecture.
I don't agree it's negligible for this purpose. Core OS functionality should run well on old/cheap machines, and throwing in unnecessary interpreters/JITs for trivial stuff is inconsistent with their recently announced commitment to "faster and more responsive Windows experiences" and "improved memory efficiency".
I'm not commenting on whether this is a good or bad thing, but the article strikes me as a bit misleading.
Either way it doesn't matter. As someone who has used Windows in a significant way since the 90s, the taskbar and start menu are a buggy mess. The new design is awful, I just want a list of my programs like before.
On that note, do we have an open standard for OS implementations? Where the fuck is our modern scratch made OS written in Rust?
It’s about time we topple this shitty triopoly.
Because that's what you get when you start from scratch.
[1] https://microsoft.github.io/react-native-macos/docs/intro
https://x.com/0xAkuKun/status/2036235161956917593
VSCode had an instant search for 10 years. Now it's broken suddenly for the first time ever. Can't search anything. Back to greping like a cave man.
sigh
React Native for Windows is quite different from embedding a web React app in the OS shell. It’s essentially a renderer that maps React components to native WinUI controls.
So saying “Windows Start is written in React” is a bit like saying an iOS app built with SwiftUI is “written in HTML”.
But surely there is some happy middle ground that doesn't end up with a entire js runtime in the damn start menu?
I'm a fairly casual dev compared to faang folk, but surely even they realised this was an awful choice?
[except for the bit that does]