mrdoob/three.js

The problem

Putting 3D into a web page used to mean writing raw WebGL, managing your own matrix math, shader plumbing and draw call ordering, or adopting a full game engine that dictates your whole application structure. three.js takes the WebGL and WebGPU layer and hands you a scene graph, cameras, materials and a render loop so a cube on screen is a dozen lines. The README is short — it is a library, not a product pitch — with the real material living on the examples and docs sites.

What's different

Compared with raw WebGL, three.js removes the boilerplate but keeps you close to the GPU: you still think in meshes, geometries, materials and lights rather than in engine-level entities and prefabs. Compared with game engines such as Unity or Godot (whose web export is a compiled runtime), it is a rendering library embedded in your existing JavaScript app — no editor, no scene file format, no opinionated lifecycle, which is exactly why it is the default choice for data visualization, configurators and WebXR experiments. The notable direction here is the shading language (three.js has been pushing its own node-based shader system, which the Hacker News thread "Three.js Shading Language" picked up) plus multiple backends: WebGL and WebGPU renderers ship in the main build, with SVG and CSS3D renderers available as addons.

Who it's for

Front-end developers and creative coders who need 3D inside a web product — product configurators, visualizations, portfolios, small WebXR scenes — and researchers or artists who want to script graphics in JavaScript. It is a poor fit if you need a full game engine with physics, level editing and asset pipelines, or if you are targeting native platforms. Teams with very large scenes should also evaluate lower-level or more specialized renderers, because three.js prioritizes ease of use over maximum render throughput.

Cost of adoption

MIT-licensed and installable from npm; the README shows import * as THREE from 'three'; with no build tooling required. Cost is mostly conceptual: understanding the scene graph and the renderer lifecycle, plus keeping an eye on release notes, since the project moves quickly and the docs include a migration guide precisely because APIs change. Cloning with full history is a ~2GB download, which is a hint at its age and scale. The README is thin on architecture and limits, so expect to learn from the examples site.

Verdict

This is about as established as a web graphics library gets: created in 2010, over 116,000 stars and 36,000 forks, with 3D, WebGL, WebGPU and WebXR all as active topics. It has not appeared on the daily trending board, but the monthly JavaScript board shows +1,355 stars in a month at #13 — steady, broad interest rather than a spike. That maturity means abundant examples and answers, and also a fast-moving API surface you must track. If you are doing 3D in the browser, this is the baseline to beat; choose something else only for game-scale requirements.