React Three Fiber vs Three.js - which one should you learn?
This is probably the first question anyone asks when getting into 3D web development. The short answer is that React Three Fiber is not a replacement for Three.js. It's a React wrapper around it. So the real question is whether you want to work with Three.js directly or through a React abstraction layer.
Both are legitimate choices, and most experienced creative developers end up knowing both. But when you're starting out, picking one to focus on makes the learning process a lot cleaner.
What each one actually is
Three.js is a JavaScript library that makes working with WebGL manageable. WebGL by itself is very low-level and verbose. Three.js gives you a scene, a camera, geometries, materials, lights, and a renderer, so you can build 3D experiences without writing raw shader code for every single thing. It has been around since 2010, has 111k GitHub stars, and gets around 5 million npm downloads a week. It's the foundation of almost everything in this space.
React Three Fiber (often called R3F) is a React renderer for Three.js, built and maintained by Poimandres, the same open source collective behind Zustand and Jotai. Instead of writing imperative Three.js code, you describe your 3D scene as React components. The underlying Three.js objects are still there, but R3F manages them in a React way. It has around 30k GitHub stars and roughly 700k npm downloads a week.
R3F is almost always paired with Drei, a companion library that gives you ready-made abstractions for common things like orbit controls, environment maps, loading 3D models, and text rendering.
The main practical difference
With vanilla Three.js you write imperative code. You create objects, set their properties, add them to the scene, and update them in an animation loop. Everything is explicit.
const geometry = new THREE.BoxGeometry()
const material = new THREE.MeshStandardMaterial({ color: 'orange' })
const mesh = new THREE.Mesh(geometry, material)
scene.add(mesh)
With React Three Fiber you describe the same scene as JSX, and R3F handles creating and updating the underlying Three.js objects for you.
<mesh>
<boxGeometry />
<meshStandardMaterial color="orange" />
</mesh>
Both produce exactly the same result. The difference is in how you structure and manage your code as things get more complex.
When vanilla Three.js makes more sense
If you are not working in a React project, the answer is straightforward: use Three.js directly. Adding React just to use R3F in a non-React context adds unnecessary overhead and complexity.
If you want maximum control over the render loop and memory management, Three.js gives you that without any abstraction getting in the way. For very performance-sensitive work, some developers prefer to stay close to the metal.
If you're coming from a game development background or you've worked with 3D engines before, the imperative style of Three.js will feel familiar and direct.
The Three.js documentation and community are also larger by a significant margin. Three.js has 5 million weekly downloads compared to R3F's 700k, so there's more existing code, examples, and Stack Overflow answers to draw from when you hit a wall.
When React Three Fiber makes more sense
If you're already working in React and your 3D work needs to coexist with a React application, R3F is the natural fit. Managing state, handling user interactions, conditionally rendering 3D objects, and integrating with React's ecosystem (React Query, Zustand, context) all become much more straightforward.
R3F also makes it easier to manage complex scenes with lots of independent pieces. In vanilla Three.js, as your scene grows, you end up writing a lot of manual bookkeeping to track what needs to be updated and when. React's component model handles a lot of that for you.
Drei saves a lot of time. Things like loading a GLTF model, adding environment lighting, or setting up camera controls that would take 20-30 lines of Three.js take one or two lines with Drei. For agency work where speed matters, this adds up.
What about bundle size?
Three.js is around 658KB parsed (roughly 155KB gzipped). R3F adds size on top of that since you still ship Three.js as a dependency, plus the React Three Fiber package itself. If you are already using React in your project, the additional cost of R3F is relatively small. If you are not using React, adding it solely for R3F is a significant trade-off.
For most creative developer work the difference is not a deciding factor, but for very lightweight or performance-critical projects it is worth keeping in mind.
What do employers actually want?
Looking at creative developer job postings, both appear regularly. Three.js shows up more often simply because it has been around longer and more developers know it. But R3F is increasingly common, especially at agencies and studios that build in React.
If you can only list one on your CV, Three.js still has broader recognition. But if you're building a portfolio, the framework matters less than what you build with it.
The honest recommendation
If you are completely new to 3D on the web and are not tied to React: learn Three.js first. Understanding how scenes, cameras, materials, and the render loop actually work will make you better with R3F later too, because R3F does not hide Three.js from you. It just gives you a different way to work with it.
If you are already comfortable with React and want to add 3D to that skill set: start with R3F. The mental model will feel familiar and you'll be productive faster.
If you want to be well-rounded as a creative developer: you'll eventually want both. Most people start with one and pick up the other fairly quickly once they have the fundamentals.
For courses on both, see the best Three.js and React Three Fiber courses in 2026.