How WinXP Is Built with React and Hooks

WinXP (winxp.vercel.app) is a browser-based recreation of the Windows XP desktop built with React and Hooks. It runs entirely client-side — no backend is involved — so the "operating system" you see is really a set of React components managing window state, a taskbar, a start menu, and individual apps like Minesweeper, Notepad, Internet Explorer, Winamp, Paint, and My Computer. This explains both why it feels like a desktop and why it depends on JavaScript to render anything at all.

The core idea: a desktop as component state

A real OS keeps track of which windows are open, where they sit, and which one has focus. WinXP does the same thing, but the "kernel" is React state.

• Functional components + Hooks — The project is described as "Windows XP in React and Hooks," meaning state and lifecycle logic live in function components rather than class components.
• Client-side only — There is no server rendering the desktop or storing your files. Everything happens in the browser tab.
• Composition over a real OS — Each visible element (window, taskbar button, start menu entry) is a component that reads from and updates shared state.

What the page evidence shows

The rendered output includes recognizable XP shell elements and apps:

This tells you the shell and the apps are separate pieces assembled into one screen, which matches the "each app is its own component" design.

How window management likely works

Window management is the part that makes it feel like an OS. In a React implementation, it usually breaks down into a few pieces of state:

1. A list of open windows — each entry holds an app identifier, position, size, and z-index (stacking order).
2. A focus/active window — clicking a window or taskbar button updates which window is on top.
3. Open/close/minimize actions — these mutate the window list, and the taskbar re-renders to match.

The input is a user action (clicking an icon, dragging a window). The action updates state. The expected result is that the desktop re-renders to reflect the new window arrangement — the same input → state → render loop React uses everywhere.

The taskbar and start menu

The taskbar is essentially a live view of the open-window list plus a clock. The start menu is a component that toggles visibility and lists launchable apps. Because both read the same state as the windows, opening an app from the start menu and clicking its taskbar button stay in sync automatically.

Why each app is a separate component

Treating Minesweeper, Notepad, Winamp, and the rest as independent components keeps the code modular:

• Isolation — A bug in the Minesweeper grid logic doesn't touch the window manager.
• Reuse — Every app plugs into the same window frame (title bar, menu bar, close button).
• Lazy rendering — An app only needs to render when its window is open.

For example, the Winamp component in the evidence shows a playlist with tracks and durations ("Diablo Swing Orchestra - Heroines (5:22)", "0:00 / 43:35"). That's self-contained UI state — playback position, track list — that doesn't need to know anything about the desktop around it.

Why it needs JavaScript (and shows a blank page without it)

The page's own notice — "You need to enable JavaScript to run this app" — is the key constraint. Because the entire desktop is rendered by React in the browser:

• If JavaScript is disabled or blocked, React never mounts, and you get a blank page.
• If a script fails to load (network, extension, or CSP issue), the same blank result occurs.
• There is no static HTML fallback of the desktop, since the shell itself is generated client-side.

So "blank page" is expected behavior when the client-side app can't start, not a sign the project is broken.

No backend required

Nothing here needs a server to function:

• No accounts or storage — Files you "create" in Notepad and drives shown in My Computer are simulated in the browser.
• No data leaves the tab — The apps are demonstrations, not real file or network tools.
• Deployment is static — Hosting on a platform like Vercel fits a purely client-side React build.

What this means for you

If you want to understand or rebuild something like this, the mental model is: one React app = a fake OS, where Hooks hold the window list and active state, the taskbar and start menu are views of that state, and each app is an isolated component mounted inside a shared window frame. The only hard requirement for it to run is a browser with JavaScript enabled.