// the find
mrdoob/three.js
JavaScript 3D Library.
three.js is the default choice for 3D in the browser — a scene graph on top of WebGL2 and (now) WebGPU, with cameras, lights, materials, loaders, and controls built in. It's for anyone shipping visual 3D on the web, from a spinning product viewer to a full WebXR scene, without hand-rolling shader boilerplate.
The loader ecosystem is genuinely comprehensive — GLTF, DRACO, FBX, USDZ, KTX2 and more are covered, so asset pipeline pain is mostly solved. The newer WebGPU renderer plus TSL (Three Shading Language) node graph lets you author one shader graph that compiles down to both WebGL2 GLSL and WebGPU WGSL, which is a real engineering win, not a gimmick. Release cadence is fast and CI is unusually disciplined for a project this size — bundle size and e2e visual regressions are tracked per PR. Docs are auto-generated per class with runnable examples, so you're rarely guessing at an API signature.
Breaking changes land often enough across releases that the migration guide is required reading, not optional — pin your version. TypeScript types live outside core (DefinitelyTyped-style) for large parts of the API surface and can drift behind new features, especially anything in examples/jsm. Speaking of which, examples/jsm (loaders, controls, post-processing passes) is not held to the same testing bar as core three — treat it as community-adjacent code, not vendor-guaranteed. The API surface is enormous, and TSL adds a second mental model (node graphs) on top of already needing to know WebGL/3D math, so the learning curve for anything beyond basic scenes is steep.