Three.js Tools, Examples & Courses for
3D Web Development, Gaming & VR.

Yes. Three.js is released under the MIT licence, which means it is free to use in personal and commercial projects, with no runtime fees and no per-seat licensing. You can read the terms on the project's GitHub repository. Paid options in this ecosystem are things built around it — courses, and boilerplates and templates — never the library itself.

Three.js is built on top of WebGL (and now WebGPU) rather than competing with it. WebGL is the low-level browser graphics API; Three.js wraps it in a scene graph, camera/light/material abstractions and asset loaders so you write far less boilerplate. Use Three.js for nearly everything, and drop to raw WebGL only where a library's abstractions cost more than they save. The full comparison goes into when that is.

Yes — it remains the most widely used 3D library on the web, and it is actively developed: recent releases added a WebGPU renderer and TSL, its new shading language. The honest caveat is that it is a rendering library, not a game engine, so for some projects a batteries-included engine is the better fit. Three.js alternatives lays out where that line falls, and the TSL guides cover the newer WebGPU work.

Nothing is strictly better — the alternatives trade Three.js's flexibility for less setup in a specific niche. Babylon.js is a more complete, batteries-included engine; PlayCanvas ships a hosted visual editor; A-Frame is a declarative HTML layer for WebXR (built on Three.js itself); and model-viewer is a zero-code web component if you only need to display one model. See the alternatives breakdown.

Pick Three.js when you want maximum flexibility and the widest choice of framework integrations (React Three Fiber, TresJS). Pick Babylon.js when you want more built in and fewer decisions on day one — it ships a physics API, a node material editor and a scene inspector out of the box. Neither is objectively better; they optimise for different teams. Full side-by-side.

React Three Fiber is a React renderer for Three.js — it produces the exact same underlying Three.js objects, just expressed as JSX instead of imperative new THREE.X() calls. So the question is really whether your project is already a React app: if it is, use R3F and gain the component ecosystem; if it is not, use vanilla Three.js rather than adding React for a feature that does not need it. Compare the two.

The API itself is approachable if you know JavaScript — a first scene is a handful of lines. The harder part is the 3D concepts underneath: coordinate spaces, lighting models, materials, and eventually shaders, none of which are specific to Three.js. Most people are productive on simple scenes quickly and then hit a slower stretch at the graphics fundamentals. Our learning path is ordered around exactly that.

It depends far more on your starting point than on the library. If you are comfortable with JavaScript, rendering a model and animating a scene is a matter of days; shaders, performance work and production-grade asset pipelines take considerably longer. Rather than guess at a number for you, we'd point at the structured courses, which state their own scope and prerequisites, and the hands-on guides for specific problems.

Start with what Three.js is and what it can do, then follow the learning path. When you hit a concrete problem, the guides are written against a stated Three.js release, and the glossary covers the vocabulary. For libraries and helpers, browse the tools directory.