Is the Windows Start Menu Actually a Website?

Every year or so a screenshot goes around claiming that the Windows 11 Start menu is a website. Usually the phrasing is “it’s literally React,” sometimes it’s “there’s a browser inside your Start menu,” and always it arrives as the explanation for why your computer feels slower than it used to.

I wanted to know whether that was true, because it’s the kind of claim that sounds too neat. It isn’t true. What’s actually there is stranger and more interesting: a middle ground between web and native that Microsoft chose deliberately, defended publicly, and is now — quietly, in 2026 — undoing.

The best part is that both sides of the argument were wrong.

What people think is in there

The mental model behind the viral version is a browser. You click Start, something like Chrome wakes up inside your operating system, loads HTML and CSS, lays it out, paints it, and hands you a menu. That would be genuinely bad. It’s also roughly what Electron apps do, which is why the accusation lands — everyone has met a chat app that eats a gigabyte of RAM to show you some text.

If that were what Windows was doing, “the Start menu is a website” would be a fair description.

And it’s worth being honest about why the claim spreads so easily: people are primed for it, because they’ve been burned before. A generation of desktop software genuinely is a browser in a costume. Chat apps, music players, note apps — a great many of the programs sitting in your taskbar right now are a web page and a copy of Chrome, shipped together, using several hundred megabytes to do something a native app did in twenty. Anyone who has watched a messaging app consume more memory than a photo editor has learned to assume the worst, and usually been right.

So when someone says the Start menu is web tech, the reaction isn’t scepticism. It’s recognition. The claim fits a pattern that is real — it just doesn’t fit this case.

What’s actually in there

Two things are true, and the gap between them is the whole post.

The first: most of the Start menu isn’t this at all. The shell — the panel itself, the search field, the pinned app grid — is C++ and XAML — XAML being Windows’ own language for describing interfaces. Native, compiled, the same stack Windows has used for years.

The second: one strip of it isn’t. The “Recommended” tray at the bottom, the one showing recently opened files, is built with React Native for Windows. Microsoft’s own sources also name the “All apps” list, though the most technically careful debunk of the viral claim mentions only Recommended — the two accounts disagree, and I’ll come back to that.

So the honest version of the headline is: one panel inside the Start menu is driven by JavaScript. Which is a much duller sentence, and also not the same accusation.

React and React Native are not the same word twice

This is where the viral claim actually breaks, and it’s a distinction worth having even if you never think about Windows again.

React draws through a browser. The thing most people mean is a web framework. Your JavaScript builds a description of a page, React works out what changed, and it writes that into the DOM — the browser’s internal model of the document. Then a browser engine takes over: it computes layout, resolves styles, rasterises everything, and produces pixels. The browser is doing the drawing.

React Native for Windows draws through Windows. It keeps the first half of that and throws away the second. You still write JavaScript, React still works out what changed. But there’s no DOM, no HTML, no CSS engine and no browser. Instead the framework calls Windows APIs directly and instantiates real native controls — actual XAML and WinUI objects, the same ones a C++ programmer would create. Windows draws them the way it draws everything else.

The JavaScript isn’t drawing your Start menu. It’s deciding what should be in it, and then asking Windows to draw the same controls Windows always draws.

That’s a real cost — you’re running a JavaScript engine that wouldn’t otherwise be there — but it is not a browser, and the difference between “a JS runtime calling native APIs” and “a webpage in your taskbar” is roughly the difference between a remote control and a television.

So why do it at all?

Not laziness, which is the usual assumption. The reason is shipping speed.

Windows ships on a schedule. If the Recommended feed is compiled into the operating system, then improving it means waiting for an OS update, with everything that implies: validation, staged rollout, months. Microsoft’s answer was to build certain experiences on React Native for Windows so they could be delivered as Online Service Experience Packs — updated independently of the OS release cycle. The Settings account page went the same way.

That’s a genuine engineering trade, and stated plainly it sounds reasonable: accept a slightly heavier runtime in exchange for being able to fix things without shipping a new Windows. Microsoft was public about it. At Chain React in 2023 they said they were choosing to trust the platform with “not only some experiences… but some of our key experiences for our users.” That is not the language of a shortcut. It’s the language of a bet.

And then they took it back

This is the part that makes the story worth telling.

In 2026, Microsoft confirmed it is rewriting those same components in native WinUI — the current toolkit for building Windows interfaces, and the successor to the XAML the rest of the menu already uses. The Recommended feed and the All apps list are being moved off React Native and back into compiled native code.

The stated reason is not memory. It’s not battery. It’s interaction latency — the delay between your click and the thing happening. Which is precisely what the people mocking the decision had been complaining about, in less polite language, for three years.

Microsoft’s VP said they had “started to integrate it into the shell at a much faster rate,” and the work was announced at Build 2026 as part of a broader push to move first-party Windows features to WinUI.

So: the viral claim was wrong. But the confident correction — it’s native underneath, it compiles down, there’s no browser, stop worrying — was also incomplete. All of that is technically accurate, and Microsoft still decided the architecture cost enough to spend engineering years unwinding it.

Being right about the mechanism doesn’t automatically make you right about the consequence.

The part that spoils a tidy ending

I’d like to finish there, with web tech losing and native winning. Two things get in the way.

Native isn’t automatically fast. In July 2026 Microsoft acknowledged that Windows 11’s native apps are themselves heavy on memory, and promised a WinUI performance push — before the Start menu rewrite lands. Read that ordering carefully: the thing they’re migrating to needs work first. “Native” is not a synonym for “efficient”; it’s a synonym for “compiled”, and a compiled program can be as wasteful as anything else.

And the JavaScript version may never have been the slow part. The author of the most careful debunk makes a point that gets lost in the shouting: there is probably a performance hit, it’s probably not large, and it may well be faster than the same panel written in C# and .NET would have been. Nobody has measured any of this in public, which means the honest position is that we do not know how much of anyone’s slow Start menu is attributable to this panel.

What Microsoft has actually said is narrower than the internet’s version of it. Not “web technology made Windows slow.” Just: for this component, moving to WinUI reduces interaction latency. That’s a specific claim about one panel, and it’s the only claim anyone has evidence for.

What I couldn’t establish

More than usual, and the gaps are the honest part of this one.

No numbers. At all. Microsoft has not published what the React Native panel actually costs — not in milliseconds of latency, not in megabytes. Nothing. So “it’s slow because of React” and “the overhead is negligible” are both, right now, opinions.

I want to flag one thing specifically, because it’s already circulating as a fact. A reported figure of around 300MB appears in coverage of this story. It is not a measurement. It’s a journalist’s hypothetical, used to illustrate the shape of an unknown number — as in, we don’t know whether this drops usage from 300MB to 250MB or to 200MB. If you see that number quoted as Windows’ actual memory use, it has escaped its context.

It hasn’t shipped. As of writing, the WinUI rewrite is announced and in progress — appearing in experimental previews of the Windows App SDK — not delivered. Nobody has measured the after, because there isn’t one yet.

And the sources disagree on scope. Microsoft’s 2026 statements name both the Recommended feed and the All apps list. The most careful technical debunk of the original claim says only the Recommended section, and notes it can be disabled. That could be a change over time, or the debunk being narrower than the truth. I couldn’t resolve it, so I’m telling you rather than picking whichever suited the paragraph.

Go and look at it

You don’t have to take any of this on faith, which is unusual for a post about someone else’s source code.

Open the Start menu on any Windows 11 machine. The pinned grid at the top responds the instant you touch it — that’s the C++ and XAML. Then look at the Recommended strip along the bottom. That’s the panel this entire argument is about.

Whether you can feel a difference between them is, genuinely, the experiment. Microsoft has decided you can. They’ve been building it the other way for seven years.

Sources

• No, Windows Start does not use React — the technical debunk. No web view or browser, React Native for Windows calling Windows APIs directly, and the scope limited to the Recommended section.
• Microsoft confirms Start menu shift to WinUI — Windows Latest, March 2026. Interaction latency as the stated reason; Recommended feed and All apps list named.
• Microsoft is rewriting Windows 11 in native code — Windows Latest, June 2026. Build 2026, the VP quote, and confirmation that no measured figures have been published.
• Microsoft admits Windows 11 native apps hog RAM — Windows Latest, July 2026. Where the hypothetical 300MB figure comes from, and its context.
• React Native for Windows — Microsoft. The framework itself.
• Settings on React Native for Windows — Microsoft DevBlog. Online Service Experience Packs, and shipping outside the OS release cycle.
• Hacker News discussion — where the claim and its corrections were argued out in public.
• React Native for Windows launch — TechCrunch, 2019. The start of the seven years.