What is Three.js? From WebGL to 3D worlds in the browser

A rotating shoe, a cloud of particles that follows the pointer, or a 3D room that unfolds as you scroll can look like video. Often, the browser is drawing it live. Three.js is one of the most common ways to begin making that kind of experience.

If the browser understands triangles, what does Three.js do?

WebGL gives a browser access to the GPU. It is powerful, but deliberately low-level: developers manage vertices, triangles, shaders, matrices, and buffers. Putting one model on a page can require a large amount of setup that has little to do with the model itself.

Three.js does not replace WebGL. It organizes WebGL around ideas that resemble the way people describe a shot: a scene contains objects, a camera establishes the point of view, lights and materials define surfaces, and a renderer draws the result into a canvas. The work is still real-time 3D, but it no longer has to begin with raw triangles every time.

Who made it? A browser experiment by mr.doob

Three.js was created by Spanish developer Ricardo Cabello, better known online as mr.doob. He published the first version on GitHub on April 24, 2010. Browsers were just becoming capable of drawing real-time 3D without a plug-in, and Cabello turned code from his interactive experiments into an open-source library.

Contributors later added much more than core features. Loaders, controls, post-processing tools, and a large examples collection grew around the engine. Three.js today is an ecosystem of the core library, add-ons, examples, and a broad community.

Five roles explain most beginner examples

The Scene is the stage that contains visible objects. The Camera is where the viewer stands; websites often use a PerspectiveCamera because nearby objects appear larger. The Renderer sends the scene and camera to the GPU, usually through WebGLRenderer.

A visible Mesh combines Geometry and Material. Geometry supplies the shape, while Material determines its color, texture, and response to light. Lights illuminate materials that need them; an unlit material can work without any light. Once these five roles make sense, most introductory Three.js examples become readable.

What can Three.js make?

The most direct use is an interactive product view. Furniture, shoes, machines, and buildings can rotate, change finish, come apart, or move into AR. Three.js also suits spatial data. Globes, network maps, and animated geographic views can reveal relationships that a flat chart does not express easily.

It is also a strong fit for interactive stories and lightweight games. GitHub Globe used Three.js to show open-source activity around the world. Google's Dreams in 3D turned written prompts into spaces to explore. Bruno Simon transformed his portfolio into a small car that visitors drive through a 3D world. In each case, 3D is not decoration; it is part of the content or the way the visitor navigates it.

Three.js can load glTF and GLB models, play skeletal animation, and render particles, shadows, reflections, and post-processing effects. It remains a JavaScript library, however. It does not decide the art direction, story, or interaction rhythm for you.

It is not Blender or a complete game engine

Three.js is good at displaying and manipulating 3D in a browser. It is not the right tool for detailed modeling, sculpting, rigging, or authoring complex animation. Those jobs are commonly completed in Blender and exported as GLB for Three.js. The tools are closer to a studio and a player than to direct competitors.

It also differs from Unity or Unreal, which provide editors, physics systems, asset management, and complete game workflows. Three.js offers flexible web building blocks. That freedom makes it easy to combine 3D with HTML, CSS, React, and normal site navigation, but developers must own performance budgets, loading states, and interaction rules.

When should you avoid Three.js?

If an image, video, or CSS can communicate the idea, 3D may add cost instead of value. Models increase downloads, continuous rendering uses power, and older phones can lose frames. Search engines and screen readers also see very little inside a canvas, so important text should remain in HTML.

I ask three questions before using it: does 3D improve understanding, is there a fallback for weaker devices, and can someone who reduces motion still read the page? If those answers are unclear, a flat version is usually the better first release.

This site: turning scroll position into a director's timeline

The KeepOnFirst 3D Studio fixes its canvas behind a normal HTML article. When a chapter enters the viewport, the program changes the focused object. Progress within the chapter controls the camera, model rotation, and lighting. If WebGL fails to load, the complete text remains available.

A scroll-driven Three.js starter

This is the smallest core, not a complete framework. It normalizes page scroll to a value from zero to one and maps that value to the camera and model with lerp. A production site should add resize handling, loading states, requestAnimationFrame throttling, reduced-motion behavior, and a WebGL fallback.

import * as THREE from 'three';

const canvas = document.querySelector<HTMLCanvasElement>('#scene')!;
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(45, innerWidth / innerHeight, 0.1, 100);
const renderer = new THREE.WebGLRenderer({ canvas, antialias: true, alpha: true });
const model = new THREE.Mesh(
  new THREE.BoxGeometry(1.8, 1.8, 1.8),
  new THREE.MeshNormalMaterial(),
);

scene.add(model);
camera.position.z = 8;
renderer.setSize(innerWidth, innerHeight);
renderer.setPixelRatio(Math.min(devicePixelRatio, 2));

let frame = 0;
function render() {
  const scrollMax = document.documentElement.scrollHeight - innerHeight;
  const progress = THREE.MathUtils.clamp(scrollY / scrollMax, 0, 1);

  camera.position.z = THREE.MathUtils.lerp(8, 3.5, progress);
  model.rotation.y = progress * Math.PI * 2;
  renderer.render(scene, camera);
}

function requestRender() {
  if (frame) return;
  frame = requestAnimationFrame(() => {
    frame = 0;
    render();
  });
}

addEventListener('scroll', requestRender, { passive: true });
render();

The hard part is rarely making a model rotate. It is making motion serve the article. Write down what the reader should notice in each chapter before designing the camera move; the result is more likely to become a meaningful 3D site instead of a collection of effects.