Three.js

Three.js is a 3D rendering library for the browser, written in JavaScript. The single thing to understand before you commit: it is a renderer, not a game engine. It draws polygons, lights, materials and cameras with real care, and it leaves gameplay, physics, audio, input handling and scene management entirely to you.

That sounds like a limitation until you notice how much interactive 3D on the web runs on it. When a product configurator lets you spin a sneaker, or a portfolio site has a floating blob that follows your cursor, this is very often what's underneath.

It sits on top of WebGL, so you get GPU-accelerated 3D without writing shaders by hand on day one. You can write shaders. Nobody is stopping you. But you don't have to open that particular door to get something on screen.

What it is good at

Getting 3D into a web page with the least ceremony. There is no separate application to install, no project format, no editor. You import the library, create a scene, a camera and a renderer, and you are drawing. The whole thing lives inside your normal front-end toolchain, which means it slots into React, Vue or a plain HTML file without a fight.

The rendering itself is the strong suit. Physically based materials, shadows, environment maps, post-processing effects, glTF model loading — the parts that make 3D look like something rather than a grey box are well covered and well documented. If your goal is "this should look good on screen," you are in the right place.

It is also genuinely good at the small, embedded stuff. A rotating logo, a data visualisation with depth, an interactive diagram, a hero animation that reacts to scroll. These are jobs a full game engine would treat like using a forklift to move a coffee cup, and Three.js handles them at exactly the right weight.

The ecosystem around it does a lot of quiet work. There are community wrappers, loaders for most model formats, and helper libraries for controls and physics that plug in cleanly. React developers in particular have a declarative wrapper that makes scenes feel like normal component code.

And because everything ships as a web page, distribution is a URL. No store approval, no launcher, no install prompt. You send someone a link and they are inside your 3D thing.

What it is not good at

Being an engine. This is the honest part, and it is the whole story. There is no editor, no scene hierarchy you click around in, no inspector, no play button. You build your world in code, and you keep track of it in your head or in your own data structures. For a small scene that is fine. For a large one it becomes architecture homework that other engines do for you.

Gameplay systems are your problem. Physics is a separate library you bolt on. Collision, pathfinding, an animation state machine, a save system, audio mixing, input mapping — none of that is included, because none of that is rendering. You will either write it or wire together packages of varying maturity, and you own the seams where they meet.

Performance management is manual and it is a real skill. The browser and the GPU will happily let you tank the frame rate, and figuring out why means understanding draw calls, geometry merging and texture budgets yourself. There is no profiler holding your hand toward the expensive thing.

It only targets the browser. That is by design and it is fine if the browser is where you want to be. But there is no official path to a desktop executable, a console build or a native mobile app. If your plan involves a storefront that isn't a web address, this is the wrong foundation.

And it assumes you can program. This is a library you talk to in JavaScript, not a tool you operate with a mouse. An artist who wants to assemble a level visually will not find a way in here.

Who should pick it

Web developers who are already comfortable in JavaScript and want 3D on a page. That is the sweet spot, and it is a large and real one. If you think in terms of the DOM, npm and a build step, Three.js will feel like a natural extension of tools you already know rather than a new universe.

It is ideal for interactive experiences that are 3D but not games in the full sense: product viewers, configurators, visualisations, immersive marketing pages, WebXR experiments, portfolio pieces. Anything where the value is a striking, responsive 3D image delivered instantly over a link.

It also suits developers who want control and are allergic to black boxes. Building your own game loop and picking your own physics library is a feature, not a chore, if you are the kind of person who finds prebuilt engines opinionated and stifling.

Who should look elsewhere: anyone making a conventional multi-level game with a lot of content, anyone shipping to consoles, and anyone who needs a visual editor because a designer or artist is doing the layout. Those are jobs for a full engine, and choosing this instead means building the engine parts yourself before you get to your actual game.

Getting started

The first hour is refreshingly short. Pull the library in, create a scene, add a camera and a WebGL renderer, drop in a cube and a light, and write a render loop that spins it. That's the classic first scene and it takes minutes, which is a large part of why people fall for this library.

Spend the rest of the hour on the fundamentals that everything else rests on: the scene graph and how objects nest, the camera and how it frames things, and materials and lighting, because that is where the "why does this look flat" questions live. Then learn to load a glTF model, since real work almost always starts from an imported asset rather than a primitive.

The official documentation and examples at threejs.org are the place to live while you learn — the examples page in particular is a working catalogue of what the library can do. If you are in React, look at the community declarative wrapper early rather than fighting the imperative API from inside components. Pricing and licensing details, if you need them, are on the official site; the library itself is MIT.