React in 3D: When <div> Becomes <mesh>

The first time someone tells you that you can build a 3D scene — a rotating model, a lit environment, a VR world — using React, it sounds like a category error. React is for interfaces. Buttons, forms, lists. Three-dimensional graphics are a different universe with their own math, their own pipeline, their own everything. Surely gluing them together is a hack.

It isn't, and the reason it isn't is the perfect note to end this series on. Because after twenty-nine articles about data fetching and forms and auth and desktop and mobile, the thing rendering React in 3D quietly proves is the idea that was underneath all of it the whole time: React was never really about the DOM. React is a system for describing a UI as a function of state and letting a renderer figure out how to make it real. The DOM was just the first and most common target. Point that same system at a 3D scene graph and it works — not as a trick, but because 3D was always within the reach of what React actually is.

So this last article is short, and it's really about a realization more than a technology. Let me show you what I mean.

The Scene Graph Is Just Another Tree

Here's the conceptual key. React renders trees. The DOM is a tree of elements — a div containing a span containing text. A 3D scene is also a tree: a scene contains a mesh, a mesh has a geometry and a material, lights and cameras sit alongside them. Same fundamental shape — a nested hierarchy of things — which means React's component model, built for exactly that shape, fits a 3D scene as naturally as it fits a webpage.

React Three Fiber is the renderer that makes this literal. It's React — real React, same hooks, same state, same composition — where the elements are 3D objects instead of HTML tags. You don't write <div>; you write <mesh>. You don't nest <p> inside <section>; you nest a geometry and a material inside a mesh.

import { Canvas } from '@react-three/fiber';

function Box() {
  return (
    <mesh rotation={[0.4, 0.2, 0]}>
      <boxGeometry args={[1, 1, 1]} />
      <meshStandardMaterial color="#22c55e" />
    </mesh>
  );
}

export function Scene() {
  return (
    <Canvas>
      <ambientLight />
      <pointLight position={[10, 10, 10]} />
      <Box />
    </Canvas>
  );
}

Read that and the uncanny thing is how ordinary it is. It's components. <Box /> is a component you could reuse, wrap in a list, conditionally render. rotation and color are just props — drive them from state and the cube animates or recolors, because it's the same reactivity you've used all series. <mesh> is to a 3D renderer what <div> is to the DOM renderer: a primitive the renderer knows how to draw. Everything you know about composing React components — props down, state-driven rendering, reuse, hooks — applies unchanged. Only the primitives at the bottom of the tree are different.

VR and AR Are Just More of the Same Realization

Once you accept that React can describe a 3D scene, VR and AR stop being a separate leap. A VR headset is, from the code's point of view, a 3D scene rendered in stereo with head tracking. AR is a 3D scene composited over a camera feed. The scene — the tree of meshes and lights and cameras — is the same tree React Three Fiber already renders; the WebXR layer adds the headset and the tracking on top.

So the progression is one idea extended, not three separate technologies to learn. Describe a 3D scene as a React tree. Render that tree to a screen — that's 3D on the web. Render it to a headset in stereo — that's VR. Composite it onto the real world — that's AR. At every step the component model is identical; what changes is the output device, exactly the way it changed when we went from browser tab to desktop window to native phone. Same React, different target. You are not learning 3D-React and then VR-React and then AR-React. You are learning that React describes a tree, and the tree can be pointed at increasingly immersive places.

The Thing This Whole Series Was Actually About

I saved this topic for last on purpose, because it makes the through-line of everything before it visible.

Look back at what we did. We fetched data and let a renderer reconcile the result. We managed state and let components re-render as a function of it. We moved React onto the desktop, onto phones, and now into three-dimensional space — and at every single stop, the same mental model carried: describe what the UI should be for a given state, and let a renderer make it real on whatever the target happens to be. The target was a browser, then a native window, then a native view, then a scene graph. The model never changed. That's not a coincidence you stumble on at article thirty — it's the thing the whole series was quietly teaching under the cover of specific problems.

React is not a DOM library. It is a way of describing UI as a function of state, with a renderer that reconciles your description against some target. The DOM was always just the first target.

That's why a React developer can move across this entire landscape — web, desktop, mobile, 3D, immersive — without starting over each time. The specifics are real and each one takes genuine learning, as every article in this series insisted. But the foundation is portable in a way that's rare in software, and 3D is the clearest proof: the moment <div> becomes <mesh> and nothing else about how you think has to change, you understand what you actually learned. You didn't learn the DOM. You learned React.

How I'd Approach It — and Where the Series Lands

Strip it to decisions:

• 3D isn't a hack on top of React. A scene is a tree, React renders trees, and React Three Fiber makes the elements 3D objects. <mesh> is the new <div>.
• Your whole component model transfers. Props, state, hooks, composition, reuse — all unchanged. Only the leaf primitives differ.
• VR and AR are the same tree, a different output device. Screen, headset, camera-composited world. Learn the scene, not three separate stacks.
• The portable asset was never the platform. It's the model: UI as a function of state, reconciled by a renderer against a target.

And that's where I'll leave the React Playbook. Thirty articles, from spinning up a project to rendering a cube in VR, and the honest summary of all of them is smaller than the page count suggests: pick tools that own the messy edges, keep your source of truth in one place, treat the client as untrusted and the boundary as sacred, and describe your UI as a function of state so it can follow you to whatever comes next. The specific libraries will churn — some of the ones I recommended will be replaced, and that's fine. The way of thinking is the part that lasts, and if this series left you with that instead of a list of dependencies, it did its job.

Thanks for reading this far. If the Playbook changed how you approach even one of these problems — or if you disagree with where I landed on some of them, which is entirely fair — I'd genuinely like to hear about it. That's the conversation that makes writing thirty of these worth it.