Beyond Three.js: Seven Libraries Doing the Heavy Lifting on the 3D Web
Photo: Ejn6699, CC BY-SA 3.0, via Wikimedia Commons
Every conversation about 3D on the web starts and ends with Three.js, and look — it earned that. But treating Three.js as the whole ecosystem is like treating React as the whole of frontend. Under the surface, a bench of specialized libraries is doing serious work in production, and knowing when to reach for each one is quickly becoming a core frontend skill.
Here are seven worth knowing, roughly in order of how often they'll save your project.
1. Babylon.js — The Full-Engine Alternative
If Three.js is a toolkit, Babylon.js is a workshop. Backed by Microsoft, it ships with a physics engine, a visual node editor, WebXR support out of the box, and a serialization format designed for real applications. Best for teams building product configurators and enterprise 3D tools where you want guardrails instead of raw flexibility. When to stick with Three.js anyway: if your bundle size budget is tight and your scene is simple, Babylon's batteries-included approach is weight you don't need.
2. React Three Fiber — Three.js for the React Generation
R3F wraps Three.js in a declarative, component-based model that React teams adopt in an afternoon. Its ecosystem (drei for helpers, leva for controls) handles the boring parts. Best for marketing sites and dashboards already living in React. The catch: it adds a reconciliation layer, and teams that don't understand the underlying Three.js API end up debugging two abstractions at once.
3. PlayCanvas — Collaborative 3D in the Browser
PlayCanvas pairs an open-source engine with a browser-based editor that real-time collaboration, Figma-style. Studios use it for advertising and branded experiences where art teams need to iterate without engineering in the loop. If your team includes designers who'll never touch a terminal, this is your pick.
4. Havok (via WebAssembly) — Physics That Doesn't Fake It
Babylon's default physics got a serious upgrade when Havok's WASM build landed. It's the same physics middleware behind countless AAA games, now running at near-native speed in the browser. Best for simulations, robotics visualization, and anything where objects need to stack, tumble, or collide believably.
5. Rapier — The Rust-Powered Physics Contender
Rapier compiles Rust to WebAssembly and is the engine behind many React Three Fiber projects. It's deterministic (same inputs, same results — critical for multiplayer), actively maintained, and fast. Best for WebXR experiences and multiplayer scenes where Havok's licensing or size doesn't fit.
6. troika-three-text — The Unsung Hero of 3D Labeling
Rendering crisp, performant text in 3D scenes is a surprisingly hard problem. Troika solves it with SDF-based text that stays legible at any zoom and renders at a fraction of the cost of texture atlases. If your scene has labels — and most data-viz scenes do — this tiny library is doing more for your UX than half your shaders.
7. glMatrix — The Math You Forgot You Needed
No rendering, no scene graph — just fast, battle-tested vector and matrix math. Every camera transform, every raycast, every custom shader uniform you compute on the CPU probably flows through glMatrix or something like it. It's the plumbing of the 3D web, and it hasn't needed to change in a decade because it's already right.
So... Should You Just Use Three.js?
Probably, yes — and that's fine. Three.js remains the best-documented, most-hirable, most-StackOverflow'd choice for general 3D web work. The point of this list isn't to dethrone it. It's that 'we use Three.js' should be a decision, not a default. When you know what Babylon, Rapier, and the rest actually do, you'll recognize the moment your project outgrows the obvious answer — and you'll know exactly what to reach for.