React Three Fiber
React Three Fiber (R3F) is a React renderer for Three.js. It is a candidate for React-integrated viewers, product configurators, and interactive visualizations, not an Aliz-recommended default.
How the Pieces Fit
| Layer | Responsibility | Example |
|---|---|---|
| Three.js | Rendering foundation: scenes, cameras, geometry, materials, and rendering APIs | Draw a lit product model |
| React Three Fiber | Express and manage Three.js objects through React components and lifecycle | Mount a model when the selected product changes |
| Drei | Reusable R3F helpers | Add camera controls or load a glTF asset |
R3F does not replace Three.js knowledge, and Drei is not a complete application engine. A configurator still needs domain rules, selection, persistence, and an undo model.
When to Evaluate It
- The viewport is part of a larger React application with HTML forms, navigation, and accessible controls.
- Application data maps naturally to scene objects, such as a catalog configuration or a network visualization.
- The team wants to keep application and viewport integration in JavaScript or TypeScript.
- Artists can author assets in Blender and export glTF; application behavior remains implemented in code. Choosing R3F does not mean modeling everything programmatically.
For example, React can own the selected product and material option while an R3F scene displays that configuration. Camera movement does not need to update every surrounding form.
Limitations and Implementation Costs
You assemble the systems the product needs: asset conventions, animation behavior, physics integration, editing tools, serialization, and undo. Drei reduces common rendering work but does not supply these as one integrated editor workflow. Compare Godot when scene authoring and behavior composition dominate the work.
Keep high-frequency updates out of React state. For animation, use useFrame with object references and delta time rather than calling React state setters every frame. For mostly static viewers, demand rendering can reduce idle work, but imperative changes must request a frame with invalidate(). See R3F performance pitfalls and scaling performance.
Do not treat WebGPU as a drop-in upgrade. Three.js has a separate WebGPU renderer with a WebGL 2 fallback, but existing custom materials, onBeforeCompile modifications, and EffectComposer pipelines require migration. Check each R3F/Drei feature you rely on instead of assuming blanket compatibility.
Alternatives
Start with the smallest tool that meets the interaction and authoring requirements.
| Candidate | Evaluate When | Main Trade-off to Check |
|---|---|---|
| Babylon.js | You want an integrated web engine with more built-in systems | Engine conventions and integration with the application UI |
| PlayCanvas | A web-first visual editor is central to the team workflow | Editor workflow, hosting, and project ownership requirements |
| Godot Web | Scene composition, animation, physics, and scripting benefit from one editor | Web export constraints and the application/runtime boundary |
| Unity Web | Existing Unity assets, expertise, or code justify the investment | Browser delivery cost and platform-specific limitations |
| model-viewer | You need straightforward model viewing or supported AR flows | Limited scope compared with a custom interactive scene application |
| Spline | Designers own embedded interactive visuals | Required custom behavior and application integration |
| CesiumJS | Geospatial coordinates, globes, terrain, or streamed geographic data are core | A geospatial platform may be unnecessary for local product scenes |
Evaluation Path
Use the Web 3D architecture cookbook to compare the same editing workflow across React + R3F and Godot-based options. Record authoring and integration effort alongside browser measurements before promoting a candidate out of triage.