three.js

three.js is the library most JavaScript developers reach for when they need real-time 3D (or 2D) graphics in a browser tab, no plugins required. It wraps the low-level WebGL and WebGPU APIs in a coherent scene graph — cameras, lights, geometries, materials, and meshes composed as objects rather than raw draw calls — so building a working scene takes a dozen lines instead of hundreds of lines of shader boilerplate.

Started by Ricardo Cabello (mrdoob) in 2010, the project has grown into the de facto standard for web-based 3D: it powers everything from product configurators and data visualizations to WebXR experiences and generative art, and ships monthly releases (r-numbered) with a large addon ecosystem (loaders, controls, post-processing, physics bridges) distributed alongside the core.

The modern core is built around TSL (Three.js Shading Language), a JavaScript-authored node system that compiles down to either GLSL (WebGL) or WGSL (WebGPU) from the same material graph — letting projects target both renderers, and eventually compute shaders, without hand-writing two shader languages.

What You Get

• A full scene graph (Object3D/Scene/Group hierarchy) with transforms, raycasting, and frustum culling handled for you
• Dual-backend rendering — WebGLRenderer and WebGPURenderer share the same TSL-authored materials so a project can target either backend
• TSL (Three.js Shading Language), a JS node-graph API for authoring shaders that compiles to GLSL or WGSL without hand-writing either
• A large catalog of geometries, standard/physical materials (PBR), lights, and loaders (glTF, Draco, KTX2, OBJ, and more) shipped as addons in examples/jsm
• Built-in animation system (AnimationMixer, keyframe tracks, skeletal/morph-target animation) and a WebXR integration for VR/AR
• 600+ runnable examples and an extensive manual/docs site (threejs.org) covering every module in the public API

Common Use Cases

• Interactive product configurators and 3D e-commerce viewers rendered directly in the browser
• Data and scientific visualization that needs true 3D perspective, point clouds, or volumetric rendering
• WebXR (VR/AR) experiences that need a scene graph rather than raw WebXR device API calls
• Generative art, creative-coding, and shader-driven visual experiments authored through TSL
• Game-like interactive experiences and 3D UI elements embedded in otherwise conventional web apps

Under The Hood

Architecture

At the center of three.js is a classic scene-graph: Object3D (src/core/Object3D.js, ~1700 lines) provides the transform hierarchy, matrix updates, and traversal that every Scene, Mesh, Camera, and Light inherits from, while Three.Core.js re-exports the renderer-agnostic pieces (math, core, geometries, materials, loaders) separately from Three.js, which layers the concrete WebGLRenderer on top — a separation that lets Three.WebGPU.js swap in the WebGPU backend against the same core object model. Rendering itself is split into a large src/renderers/ tree with parallel webgl/ and webgpu/ subfolders sharing a common/ layer, and a src/nodes/ tree (accessors, core, display, lighting, math, procedural, tsl) that implements the node-graph compiler feeding both backends — the architecture’s central bet is that authoring shaders as composable node graphs, not backend-specific shader strings, is what lets one material definition target two entirely different graphics APIs. What would break if that abstraction changed: virtually every downstream addon in examples/jsm, since materials, post-processing passes, and loaders all consume the node system’s public surface.

Tech Stack

Pure JavaScript (ES modules, no required TypeScript, though .d.ts-adjacent type packages exist separately) with zero runtime dependencies — the entire 3D math (src/math/), scene graph, and renderers are hand-rolled rather than delegated to third-party libraries. The build pipeline uses Rollup (utils/build/rollup.config.js) to produce ESM and CJS bundles (build/three.module.js, build/three.cjs, plus a dedicated build/three.webgpu.js and build/three.tsl.js), and ESLint (flat config, eslint.config.js) enforces style across src, examples, editor, manual, test, and utils as separate lint targets. Distribution is npm-native (package name three) with addons (loaders, controls, postprocessing) shipped as ES modules under examples/jsm/ rather than bundled into the core, keeping the core package lean while still being installable from the same package.

Code Quality

Testing uses QUnit across 264 unit test files under test/unit/src/ (mirroring the src/ module layout one-for-one, e.g. test/unit/src/core/BufferAttribute.tests.js) plus addon tests under test/unit/addons/, run headlessly through Puppeteer (test/unit/puppeteer.unit.js); there’s a separate end-to-end visual-regression suite (test/e2e/) that renders the example gallery and diffs screenshots, plus a tree-shaking test (test/rollup.treeshake.config.js) that verifies unused modules are actually eliminated from bundles. Error handling favors explicit throw/console.error at API boundaries (e.g. BufferAttribute rejecting non-typed-array input) over silent failure, naming is consistent and PascalCase-for-classes throughout, and CI (.github/workflows/ci.yml, plus dedicated CodeQL, bundle-size-report, and protected-folders workflows) runs lint, unit, and e2e suites on every change — a maturity level consistent with a 15-year-old project maintained by a large, active contributor base (2,554 contributors).

API Design The public API optimizes for the “twelve lines to a rendered cube” experience shown in its own README: new THREE.Scene(), new THREE.PerspectiveCamera(), new THREE.Mesh(geometry, material), renderer.render(scene, camera) — a handful of composable primitives rather than a large configuration object. TSL extends that ergonomics story into shader authoring: instead of writing GLSL/WGSL strings, developers compose small JS functions (vec3(), mul(), texture(), etc.) that read like normal JavaScript and get compiled per-backend, which meaningfully lowers the barrier to custom materials compared to hand-written shader code. The tradeoff is API surface size — the full module catalog (geometries, materials, loaders, nodes, controls) is large, and the migration guide wiki exists specifically because the r-numbered release cadence (roughly monthly) does introduce breaking changes across the 100+ documented releases in the project’s history.