Choosing a Web 3D Architecture

Choose who owns scene behavior before choosing an embedding mechanism. This cookbook compares React + React Three Fiber, a React shell with Godot, and a Godot-first application using one bounded editing workflow.

note

These are candidate architectures and proposed evaluation tasks, not results from a completed prototype or a recommended default stack.

Project Context

Consider a browser-based room or product layout tool. Users open a project, select an object, edit a property, manipulate it in a viewport, undo the change, and save the result. The application also needs navigation, authentication, and project management.

The decision is about scene ownership, authoring, and application integration. It is separate from Choosing a Rendering Architecture, which covers SPA, SSR, and static rendering for web pages. A server-rendered shell still needs a client-side interactive 3D runtime.

Tech Stack Candidates

Candidate	Application Layer	Scene Layer	Why Evaluate It
React + R3F	React, TypeScript, HTML forms, backend API	Three.js through R3F, with selected Drei helpers	The viewport is closely tied to React data and web UI
React shell + Godot	React owns web workflows and backend integration	Godot export owns scene behavior and editing	Integrated scene authoring may justify a separate runtime boundary
Godot-first	Godot owns most UI and interaction; a web adapter handles browser integration	Godot scenes and scripts	The product is primarily a scene experience with limited surrounding web UI

Use the R3F triage page for library roles and alternatives. Use Godot Web for export restrictions and threading requirements. Neither engine choice implies a performance advantage.

Architecture Overview

React + R3F

Keep committed domain state and undo in one application model. React presents forms and declarative scene structure; R3F handles the Three.js scene. Camera motion and frame-by-frame animation stay in the scene layer rather than causing application-wide React updates.

For example, both an HTML width field and a viewport resize handle issue the same domain command. The scene and inspector display the accepted result. Blender/glTF can supply authored assets, but editing rules and behavior systems still need implementation.

React Shell + Godot

React owns authentication UI, navigation, forms, projects, and API calls. Godot owns canonical in-session scene state, manipulation, and undo. A small command/event bridge connects them; React displays a projection of accepted runtime state rather than maintaining a second scene model.

This introduces two build pipelines and a lifecycle boundary. It may be worthwhile when Godot's editor, animation, physics, and scripting reduce authoring effort. The React + Godot cookbook develops this option.

Godot-First

Godot owns most screens as well as the scene. Browser integration and backend access remain explicit work, and the server still enforces authorization. This can fit a simulation or scene-centric tool with few conventional web workflows.

Do not count canvas-based controls as equivalent to semantic HTML. Budget a DOM layer for accessible object selection and property editing where required. If that layer grows into a substantial web application, reconsider the React-shell option.

Key Patterns

• One command path: An inspector edit and a viewport gesture must reach the same validation and undo logic. A width change should not behave differently depending on its input surface.
• Authoring is a separate axis: Compare the effort to add an animated, selectable object, not just the effort to render a mesh. R3F can consume authored assets; Godot does not automatically supply an end-user editor.
• Persist domain data: Save stable object IDs, allowed asset references, and editable properties. Reconstruct runtime objects from validated data instead of persisting engine internals.
• Separate draft and committed state: A partially typed property value is a form draft. Only accepted commands change the scene and its revision.
• Keep browser UI usable: Provide keyboard-accessible HTML object and property controls, and test focus movement into and out of the viewport.

Evaluation Tasks

Shared Workflow

Use the same modest asset set, lighting, editable fields, camera limits, and acceptance criteria for each candidate. For Godot-first, include a minimal HTML property control so the browser integration requirement is still exercised.

1. Load a saved layout containing a few representative objects with stable IDs.
2. Select an object through the viewport and through an HTML object list.
3. Change a property in an HTML inspector and confirm the accepted value appears in the scene.
4. Manipulate the object in the viewport and confirm the inspector receives the committed result.
5. Undo the gesture as one operation, then undo the property edit.
6. Save a versioned domain snapshot, reload the application, and verify the same layout.
7. Exercise loading failure, runtime reload, and navigation with unsaved edits.

Evaluation Rubric

Agree on budgets and weights before implementation. Treat required browser support, accessibility, and hosting policies as pass/fail gates; a high average score must not hide a failed requirement.

Dimension	Evidence to Collect
Cold startup	Transfer size and elapsed time to an interactive scene on a cold cache and representative network
Mobile memory	Available browser/device memory measurements, reload or crash behavior, and repeated project-open behavior; record measurement limitations
Interaction	Frame times and input responsiveness during the same manipulation, asset load, and property edit
Authoring effort	Time and steps to add an asset, collision, animation, and one new behavior; include iteration/export time
Integration effort	Work needed for selection synchronization, forms, undo, persistence, lifecycle, and browser authentication flows
Accessibility	Keyboard completion of the workflow, useful DOM semantics, and predictable focus across the viewport boundary
Deployment	Export/build workflow, cache behavior, embedding policies, and any required isolation headers

Record device, browser, network, asset sizes, build mode, and export settings with measurements. Compare equivalent visual quality and repeat runs. An empty scene or a desktop-only frame-rate result is not enough to select an architecture.

Decision Record

Document which candidates pass the gates, their measured results, engineering effort, and remaining risks. Choose React + R3F when close web integration and a manageable scene system make it the simpler fit. Choose a React shell + Godot when demonstrated authoring savings outweigh bridge and deployment costs. Choose Godot-first when the scene experience dominates and the remaining web and accessibility work stays bounded.

If all candidates miss the budget, reduce the scene or interaction scope, or evaluate a narrower tool from the alternatives table. Do not promote a candidate out of triage based on this document alone.

Exclusions

• No prototype, benchmark results, production scaffold, or effort estimate is supplied here.
• No multiplayer collaboration, conflict-free replicated data types, arbitrary scripting, or full CAD editor.
• No engine-wide ranking or claim of native/web feature parity.
• Detailed Godot export rules and alternative-engine comparisons belong to the linked triage pages.