The Shift to Spatial: How Claude Opus 5.5 and Three.js Are Reshaping the Flat Web

For nearly three decades, the browser has been a flat canvas a digital newspaper built from rectangles, images and links. To build a standard webpage, developers used HTML for structure, CSS for layout and JavaScript to handle actions such as clicking a button or opening a menu.

That model isn’t going away. Most of what we do online, from reading and comparing to buying and filling in forms, is still best served by fast, accessible, well-structured pages. But alongside it, something new has become practical. Interactive 3D experiences that once needed a specialist studio can now be built, tested and shipped by ordinary web teams.

Three things are driving this:

WebGL (and its successor, WebGPU), the Three.js library, and AI models such as Claude Opus 5.5. Together, they let a standard web page render interactive data visualisations, real-time product showrooms and even games, with no app download required.

The tech stack explained: from silicon to screen

To understand why this is happening now, it helps to know how a computer divides its work.

A typical website leans on the CPU (Central Processing Unit), the general-purpose “brain” of your device. Modern CPUs have several cores and handle a huge variety of tasks well, but they only work on a handful of things at once. Ask a CPU alone to calculate the colour of every pixel in a moving 3D scene and your browser will struggle.

The 3D web moves that workload to the GPU (Graphics Processing Unit). A GPU is less versatile, but it contains thousands of small cores designed to run the same simple calculation across millions of pixels at the same time. That is exactly what graphics need.

The modern 3D web uses a three-tier structure to tap into that power:

[ Your web page ]
       │
       ▼
 ┌───────────┐
 │ Three.js  │  ◄── The translator: turns readable JavaScript into 3D instructions
 └─────┬─────┘
       │
       ▼
 ┌───────────┐
 │   WebGL   │  ◄── The bridge: the browser API that talks to the graphics hardware
 └─────┬─────┘
       │
       ▼
 ┌───────────┐
 │    GPU    │  ◄── The engine: hardware that draws millions of pixels, ideally 60 times a second
 └───────────┘

1. WebGL (the bridge)

WebGL is built into every modern browser and gives web pages a secure route to your device’s graphics card. It can draw almost anything, but it is notoriously low-level. Displaying a single lit, spinning cube in raw WebGL takes around a hundred lines of dense code defining vertices, matrices and shader programs. Its successor, WebGPU, is faster and more modern, and is now rolling out across browsers.

2. Three.js (the translator)

Because raw WebGL is so laborious, most of the industry builds on Three.js, an open-source library that wraps it in understandable concepts. Instead of calculating matrices by hand, a developer creates a scene, adds a camera and a light, and places objects in it. Three.js handles the maths and talks to WebGL, and in recent versions it can target WebGPU too.

3. Claude Opus 5.5 (the collaborator)

Three.js makes the code readable, but building a good 3D scene still takes geometry, a feel for camera movement and a lot of performance tuning. This is where AI models such as Claude Opus 5.5 come in.

A developer can describe a scene in plain English, and the model can write the Three.js code, explain how the maths works, and revise it when something looks wrong. What used to be weeks of specialist work can become an afternoon of back-and-forth.

That speed comes with a caveat:

AI-written graphics code is not automatically correct. Models get API details wrong between library versions, produce effects that look subtly off, and write code that runs smoothly on a laptop and stutters on a cheap phone. The demo in this article is a good example. The first version had several bugs, which are covered below. The real gain is iteration speed with a human reviewing the output, not flawless code on demand.

Under the hood: How the demo works

The demo at the top of this article is a single self-contained snippet. It creates about 1,500 glowing points arranged in a sphere, lets them drift gently, and parts them around your cursor or finger.

Here is the heart of it, the loop that runs every frame:

for (var i = 0; i < count; i++) {
  var j = i * 3, p = phase[i];

  // Bounded drift around a fixed home, so the sphere never falls apart
  var x0 = home[j]     + Math.sin(time * 0.4 + p) * DRIFT;
  var y0 = home[j + 1] + Math.cos(time * 0.3 + p) * DRIFT;
  var z0 = home[j + 2] + Math.sin(time * 0.35 + p * 1.3) * DRIFT;

  // Rotate the target slowly around the vertical axis
  var tx = x0 * cosA + z0 * sinA;
  var tz = -x0 * sinA + z0 * cosA;
  var ty = y0;

  // Part the particles around the line from the camera through the cursor
  temp.set(positions[j], positions[j + 1], positions[j + 2]);
  raycaster.ray.closestPointToPoint(temp, closest);
  // ...push each nearby particle directly away from that line

  // Spring back towards the target
  positions[j]     += (tx - positions[j])     * RETURN;
  positions[j + 1] += (ty - positions[j + 1]) * RETURN;
  positions[j + 2] += (tz - positions[j + 2]) * RETURN;
}
positionAttr.needsUpdate = true; // re-upload positions to the GPU

Each particle has a fixed “home” on the sphere. Every frame, the code works out where that particle should be once drift and rotation are added, checks whether the cursor’s line of sight passes close to it, and pushes it aside if so. A gentle spring then pulls it back, which is what gives the effect its elastic feel.

What the first draft got wrong

The original AI-generated version of this demo looked convincing but had problems that only show up when you run it:

• A broken library link. It loaded Three.js from Cloudflare’s homepage rather than from an actual file, so nothing rendered at all.
  
• A sphere that slowly dissolved. The drift was added to each particle’s home position every frame, so the particles wandered off indefinitely and the shape thinned out within minutes.
  
• An overly violent cursor. The push force was so strong relative to the spring-back that particles were flung away and jittered at the edge instead of parting smoothly.
  
• A cursor that missed its target. The sphere rotated, but the interaction ignored that rotation, so the gap drifted away from the pointer.
  
• Page-breaking layout. It disabled scrolling on the whole page and sized itself to the full window, which would have covered this article.

None of these would be caught by reading the code quickly, and all of them were obvious within seconds of testing. That is the practical lesson for anyone building with AI: generate fast, but always run it, and run it on a device.

Why “vibe coding” has reached 3D

Source: Ryan Sael @RyanSael

The bottleneck for the 3D web was never the hardware. It was the time and specialist knowledge the code demanded, from matrix maths to GLSL shader languages.

Generative AI is lowering that barrier. The phrase “vibe coding,” popularised by AI researcher Andrej Karpathy in early 2025, describes building software by describing what you want and letting an AI write the code, often without reading every line. It is sometimes used with a hint of irony, since skipping review is exactly how bugs like the ones above slip through, but the underlying shift is real.

Three things make 3D a particularly good fit:

1. Plain-language prototyping. A designer can describe an experience, such as “a slow-moving data universe where nodes expand into product details when you hover over them,” and see a working prototype in minutes rather than waiting for an engineering sprint.
   
2. A framework AI handles well. Three.js has a consistent, well-documented structure, which makes AI-written code for it more reliable than code for many less predictable tools. It still needs testing, but it is a strong starting point.
   
3. Faster asset pipelines. 3D models in standard formats such as .glb and .gltf slot straight into Three.js, and AI tools are increasingly able to help create or adapt those assets.

Built for real devices

A 3D effect that drains a phone battery or freezes an older laptop is worse than no effect at all. The demo on this page includes a few habits that should be standard for any spatial web feature:

• It uses fewer particles on small screens and caps pixel density, which reduces the work the GPU has to do.
• It pauses completely when you scroll it off screen or switch tabs, so it isn’t using power when nobody can see it.
• It respects your device’s “reduce motion” setting by switching off the automatic drift and rotation.
• It works with touch as well as a mouse, and still lets you scroll the page with a vertical swipe.
• It shows a clear message instead of a blank box if your browser can’t run WebGL.

Just as importantly, the article itself doesn’t depend on the demo. If the 3D layer fails, every word here still loads. Spatial features should enhance a solid page, not replace it.

What this means for business

Moving from 2D to 3D is not a goal in itself, but where depth carries meaning, it can change how people engage.

E-commerce. Online shops can move beyond static image grids towards interactive showrooms. Customers can rotate a product, zoom in on textures, switch materials in real time, or see an “exploded view” of how the parts fit together. For simple product viewing, tools such as Google’s open-source component deliver much of this with very little code.

Financial services and data. Some data genuinely has more than two dimensions. For relationships across portfolios, networks or time, a navigable 3D view can reveal patterns that a stack of bar charts hides. The caveat is that 3D charts can also distort comparisons, so they work best for exploration rather than precise reporting.

Entertainment. Games and interactive stories can run from a simple link, with no app store download. The browser adjusts the graphics to match what the visitor’s device can handle, though demanding titles still perform better as native apps.

The boundary between desktop software and a web address is thinner than it has ever been. It hasn’t vanished, and native apps still win on raw performance, offline use and hardware access. But for the first time, going beyond the flat page is a design decision rather than a budget decision. That is the real shift.

Want to hear more?

Want to hear more about how we’re using Claude Opus 5.5, Three.js and WebGL to explore real-world problems? Mark Martin MBE will be exploring air pollution as part of our new partnership with Black in Academia.

FRONTIERS SERIES: Launch Event

Join us as we kick off the FRONTIERS SERIES, a new partnership between Black in Academia and the UKBT Institute putting Black-led research at the centre of the conversation.

What to expect

Paulette Williams will open with a look at Leading Routes, its work through Black in Academia, and the mission to amplify the visibility, influence and reach of Black researchers.

Mark Martin MBE will lead our first Frontiers conversation, diving into the UKBT Institute’s Air Pollution Project and looking at how data, technology and community knowledge are coming together to tackle air-quality challenges where it matters most.

Wednesday 14 October 2026 18:00–19:30 Online via Zoom

Save your spot below.

Register for the launch event