Start with the decision
There is no useful universal ranking for Three.js tools or rendering architectures. A reference manual, an Agent Skill, an MCP tool, a renderer, and a shader language solve different problems. The useful question is which option owns the decision in front of you.
Use the ecosystem comparisons when choosing how an agent should obtain knowledge or runtime capability. Use the technical comparisons when choosing the rendering mechanism that will enter the codebase. Each leaf states when both options can coexist and when migration is actually required.
Workflow and resource comparisons
| Decision | Use this comparison | What it resolves |
|---|---|---|
| Upstream reference or agent workflow | Skill pack vs official Three.js docs | API authority, architecture guidance, examples, revision boundaries, and verification |
| Reusable skill or one-off instruction | Skill pack vs general AI prompts | Repeatability, project context, progressive loading, and maintenance |
| Renderer specialist or full game workflow | Skill pack vs Three.js Game Skills | Advanced rendering systems versus complete browser-game production |
| Specialist pack or broad Claude plugin | Skill pack vs Three.js Skill Plugin | Specialist routing versus one broad repo-first skill |
| Instructions or callable runtime capability | Agent Skills vs Three.js MCP tools | Architecture knowledge, live inspection, tool side effects, and combination rules |
These are not winner-take-all choices. Official documentation is the primary reference for documented Three.js APIs, imports, and properties; exact behavior still requires installed-revision source and a relevant runtime reproduction. A good project prompt remains necessary even when a specialist skill owns the workflow. An MCP server can complement a skill when the agent needs live state that static instructions cannot provide.
Architecture comparisons
| Decision | Use this comparison | Governing boundary |
|---|---|---|
| Shader authoring model | Three.js TSL vs GLSL | WebGPURenderer node graphs versus established WebGLRenderer shader source |
| Renderer and backend | WebGPURenderer vs WebGLRenderer | Required features, actual backend, compatibility, migration cost, and measured workload behavior |
| Post-processing owner | RenderPipeline vs EffectComposer | WebGPURenderer node composition versus WebGLRenderer pass chains |
The renderer comparison should normally be read first. It constrains the valid material and post-processing choices. TSL does not turn a WebGLRenderer application into a native WebGPU application, and naming a WebGPURenderer object does not prove that its active backend is WebGPU.
Criteria used on every page
The pages compare primary job, supported renderer and backend, version boundary, runtime requirements, source authority, validation model, migration cost, maintenance source, and failure conditions. Technical pages also state assumptions about passes, storage, lifecycle, and invalidation where those affect the choice.
No score bars are used. A feature count cannot explain whether a system owns the final output transform, whether a live tool may mutate a scene, or whether an existing GLSL estate makes migration uneconomic.
What this hub cannot decide
These comparisons are not performance benchmarks. Renderer and pipeline cost depends on the scene, device, backend, attachment formats, effect graph, and measurement method. Ecosystem facts can also change after the displayed review date. Follow the linked primary source before making a decision that depends on current compatibility, license, or installation details.
If the choice is still wider than two options, use the alternatives hub. If the architecture is chosen and the question is adoption, continue to the migration guides or user docs.