A small scene API opens into a very large graphics toolkit
The basic three.js program is still easy to explain: create a scene, camera, geometry, material, mesh, and renderer, then update the mesh inside an animation loop. That direct model helps newcomers see where pixels come from. It also stays useful as projects grow because the application owns scene structure and timing instead of conforming to an editor's object model.
Beyond the core, addons cover controls, asset loaders, post-processing, helpers, effects, and alternate renderers. The current builds focus on WebGL and WebGPU, while SVG and CSS3D renderers remain available as addons. This split keeps the main package from pretending every renderer has equal status. It also means developers must read import paths carefully and decide which examples are suitable foundations rather than production-ready modules.
The repository is large because examples are part of the product
Our shallow checkout contained 5,886 files, roughly 580,345 source lines, and 594.5 MB. The README warns that cloning all Git history is about 2 GB and recommends git clone --depth=1 when history is unnecessary. That size is unusual for a JavaScript library, but three.js ships years of examples, test assets, docs, an editor, and renderer work in one repository.
The examples are often the quickest route to a technique such as glTF loading, shadows, post-processing, WebXR, or GPU computation. Copying one blindly is risky. An example may prioritize showing one API over cleanup, asset licensing, responsive layout, accessibility, or low-power devices. Start from the smallest relevant case, then add explicit disposal, loading states, resize handling, and a reduced-motion or static fallback where the product needs one.
What happened when we ran it
Our sandbox installed 235 npm packages in 30 seconds and used 147 MB on disk. The build completed successfully in 10 seconds. Node's test runner then passed 1,315 of 1,315 tests in 29 seconds. Npm audit reported 0 known vulnerabilities across critical, high, moderate, and low severities for the dependency set at commit cbba126.
The measured repository had 6 CI workflow files and a tests directory, with no Dockerfile. The green Node suite is meaningful for core logic and packaging, but it cannot cover every browser, graphics driver, extension, or visual output. Our 3-CPU, 8 GB unprivileged container did not judge frame rate, memory use in a scene, WebXR comfort, or image correctness. Those require a chosen workload and target devices.
WebGPU is usable, while its edges move daily
Release r185 contains extensive WebGPU renderer, node, compute, texture, binding, and XR work. On August 26, 2026 alone, pull requests addressed stale bind-group reuse, render-target dimensions, disposed GPU buffers, clustered-light cleanup, and stereo camera handling. That activity is good for fixes and a warning against assuming the newer renderer behaves identically to WebGL across every feature.
The issue trail gives concrete test cases. Issue #34343 described severe pose-linked world drift in desktop PCVR on the WebGPU path while WebGL worked on the same hardware; it was closed after follow-up. Pull request #34378 fixed an uncaught compileAsync() failure when a material was disposed during compilation. If WebGPU or XR is central, maintain a device matrix and reproduce the exact renderer, browser, headset, and disposal sequence before release.
A passing suite still has known coverage holes
Our run passed 1,315 tests, yet issue #34371 found unit files that registered QUnit modules without any assertions. Pull request #34372 proposes adding 276 tests across 17 of those files. This does not invalidate the passing cases. It shows why a large count should be read as evidence for covered behavior, rather than proof that every renderer subsystem has a meaningful unit test.
Visual regression tests and live examples add another layer, but application-specific scenes remain your responsibility. Test asset loading failures, context loss, resizing, device-pixel ratios, color management, disposal, and tab suspension. For interactive work, keyboard operation and alternative content should be product requirements, because a canvas alone offers little structure to assistive technology. three.js gives rendering primitives; it does not supply an accessible interface around them.
Monthly releases make pinning and migration routine
The latest published release was r185 on July 1, 2026, while the default development branch was pushed on August 26. GitHub listed 114,816 stars and 379 combined issues and pull requests. Those figures describe one of the largest active browser graphics communities, with a queue that includes feature work, defects, docs, and experimental renderer changes rather than 379 confirmed bugs.
Release notes and the migration guide are required reading because deprecated APIs are removed and renderer internals evolve. Upgrade in a branch, run representative scenes, compare screenshots, and watch the console for warnings. Teams that cannot schedule that work should pin a known release. For teams that can, three.js offers unusual freedom without forcing the rest of the application into a game-engine architecture.