When this project started, the choice between Three.js and Babylon.js was anything but obvious. Both are excellent. Both have WebGL 2 and WebXR support, active communities, and TypeScript definitions. After prototyping several simulations in each, Three.js won. Here's why — and why Babylon.js would win in a different project.
Head-to-Head Comparison
| Criterion | Three.js r168 | Babylon.js 7.x |
|---|---|---|
| Min bundle (gzip) | ~150 KB (core) | ~420 KB (min core) |
| API philosophy | Thin wrapper, explicit control | Full engine, batteries included |
| Scene graph | Object3D tree | Node-based, more auto-management |
| Custom shaders | ShaderMaterial — minimal boilerplate | ShaderMaterial + node editor |
| PBR materials | MeshStandardMaterial | PBRMaterial (more parameters) |
| Post-processing | EffectComposer (separate pkg) | PostProcessingPipeline (built-in) |
| Physics built-in | No (use Cannon.js, rapier, etc.) | Havok, Ammo.js built-in |
| XR / VR | WebXR controller support | Full XR mode out-of-box |
| npm downloads/week | ~1.5M | ~200K |
| Tree-shaking | Full ESM, excellent | Partial, improving |
| Community / tutorials | Massive (drei, r3f, etc.) | Strong, especially game devs |
| Inspector / devtools | Three.js devtools (browser ext) | Built-in inspector panel |
The Bundle Size Argument
Each simulation on this site loads independently. A 270 KB difference per page × 40 simulations means at worst ~11 MB of extra transfer if a user visits everything. With HTTP caching, the library is loaded once — but the first download matters for mobile users and Core Web Vitals. Three.js ships as fully tree-shakeable ESM modules; unused classes disappear at build time.
Custom Shaders Are the Core Business
Almost every visual effect here is a custom GLSL shader: ocean waves
(Gerstner), fluid rendering (screen-space normals), galaxy (GPU point
billboards), reaction-diffusion (ping-pong framebuffers). Three.js's
ShaderMaterial is just:
- A vertex shader string
- A fragment shader string
- A
uniformsdict
No node graph, no abstraction to fight. You write GLSL, that's what
runs. Babylon.js's ShaderMaterial is similar, but if you
start with their built-in materials (PBRMaterial, StandardMaterial),
the mental model is an engine that generates shaders — there's more to
override when you need full control.
When You Should Pick Babylon.js
You should not follow this project's choice if your goals include:
- A 3D game with physics — Babylon's Havok integration is production-grade. Three.js needs Cannon.js or Rapier wired in manually.
- Non-technical artists — the Babylon.js node material editor and Blender exporter pipeline are excellent for designers.
- VR/XR as a first-class feature — Babylon's XR mode handles controller input, hand tracking and teleportation out of the box.
- An enterprise with slow build pipelines — Tree-shaking differences matter more for fast bundles than for intranet apps behind a CDN.
TL;DR — Three.js wins for data-driven science simulations that live or die on custom GLSL and minimal bundle overhead. Babylon.js wins for full games, rich interactive experiences, and anything needing built-in physics or VR.