TresJS: building Three.js scenes as Vue components

The problem TresJS solves for Vue teams

Three.js is imperative. You construct a scene, add a camera and a renderer, append a canvas, and then keep mutating objects in a requestAnimationFrame loop. In a Vue application that means the 3D layer lives outside the component system: its state is not in refs, its lifecycle is not tied to onMounted and onUnmounted, and every scene change is a manual call. TresJS closes that gap. The README describes it as "Declarative ThreeJS using Vue Components", and the repository describes the project as a way of creating Three.js scenes with Vue components in a declarative fashion. The audience is narrow and specific: developers who already write Vue and want a scene graph that reads like the rest of their templates. If your application is React or Svelte, the project offers nothing, because the whole mechanism is a Vue custom renderer.

How the custom renderer maps components onto Three.js objects

The README states that TresJS is built on top of a Vue Custom Renderer and is powered by Vite. That single sentence explains most of the design. A custom renderer replaces Vue's DOM node operations with your own, so the renderer decides what a "node" is. In TresJS the nodes are Three.js objects, and the component tree becomes the scene graph. Because the renderer is Vue's, the reactive primitives still apply: props map to object properties, and updating a prop updates the corresponding Three.js object rather than rebuilding the scene. The README also claims the project "brings all the updated features of ThreeJS right away regardless the version", which is a design promise rather than a compatibility layer. There is no translation table between a TresJS API and a Three.js API; the components stand in for Three.js constructors directly. That is why the project describes its maintenance goal as "0-to-none": new Three.js features are reachable without waiting for a wrapper to be written. It is also why the ecosystem is split into packages rather than one bundle. The README lists Tres (the core), Cientos (helpers), Post-processing, Nuxt, and TresLeches, and the monorepo layout under packages/ matches that list.

Installing @tresjs/core and rendering a first mesh

The README points to the installation guide at docs.tresjs.org/getting-started/installation rather than repeating the steps, and the package name used throughout the ecosystem table is @tresjs/core. The repository's own package.json declares the workspace's package manager and its scripts, which is what you would run if you were working inside the monorepo rather than consuming the published package. The repository root package.json shows the following entry.

"packageManager": "[email protected]"

That pin applies to contributing to the monorepo. As a consumer you install the published package into your own Vue project. The README does not reproduce the install command or the component shape; it links out to the installation guide, and the getting-started path in the docs is where the exact component names and props live, because the canvas component and the scene component are separate pieces with different props. The naming convention is the first thing to internalise: a Three.js class such as Mesh or BoxGeometry appears as a component prefixed with Tres. The README also notes that the project is "Fully Typed", so your editor should offer completions on those component props once the package is installed. If the canvas renders blank, the usual cause is a canvas that has no height: the renderer fills its parent, and a parent with zero height produces nothing visible.

Where TresJS stops helping you

The declarative layer covers scene construction, not scene performance. Vue's reactivity is a cost, and a scene with thousands of individually reactive objects will pay it on every update. TresJS does not hide that; it also does not solve it. The escape hatch is the same as in any Vue application, which is to keep large, frequently changing data out of the reactive graph and mutate Three.js objects directly. The second limitation is the version coupling. The README's claim that features arrive "regardless the version" means TresJS does not insulate you from Three.js changes. When Three.js renames or removes something, your components follow. Teams that adopted a wrapper precisely to avoid that churn will find this the wrong trade. Third, the documentation is the source of truth for component props and events, and the README does not reproduce them; it links out. Anyone evaluating TresJS should read the docs rather than the README, because the README is a signpost. Finally, this is a rendering library, not a scene-authoring tool. There is no editor, no asset pipeline, and no loader UI in the core package. The related search term "Three js 3D models free" points at a need TresJS does not address: you still source your own glTF or other assets and load them yourself.

TresJS compared with React Three Fiber

React Three Fiber is the obvious reference point, and it appears in the related searches. The two projects solve the same problem for different frameworks, and the difference is not cosmetic. R3F builds on react-three-fiber's reconciler and expresses scenes through JSX, with hooks such as useFrame for the render loop. TresJS builds on Vue's createRenderer API and expresses scenes through templates, with Vue's own lifecycle and reactivity in place of hooks. If your team writes Vue, the R3F approach means introducing React into the codebase or running two frameworks; if your team writes React, TresJS is not an option at all. The second difference is packaging. TresJS ships the ecosystem as separate npm packages (core, Cientos, post-processing, Nuxt), so you install only what you use, while a scene that needs post-processing pulls in @tresjs/post-processing explicitly. That granularity is a real advantage for bundle size and a real cost in version bookkeeping, since the packages release independently. The recent release list shows @tresjs/post-processing at 3.8.0 and @tresjs/rapier at 1.1.0, which is the kind of version spread you should expect to manage.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and independent per package: @tresjs/[email protected] on 2026-09-22, and @tresjs/[email protected] and @tresjs/[email protected] both on 2026-09-14. The 0.1.0 on the CLI package is worth noting on its own: a package below 1.0 has no stability promise, and you should not assume its flags will survive a minor bump. The monorepo uses Nx for task orchestration and pnpm workspaces, with scripts such as build, test and typecheck running across packages. The root package.json shows how those are wired.

"build": "nx run-many --target=build"

That matters to you only if you intend to contribute or vendor a fork; as a consumer you are installing published packages. The licence is MIT, declared in both the repository root package.json and the LICENSE file. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved. That is a general description of the licence text, not legal advice, and your own counsel should review anything you ship. One practical consequence of the MIT plus multi-package setup is that forking a single package is straightforward if you need a patch faster than upstream can merge one.

Editorial conclusion

Adopt TresJS if your application is already Vue and you want the scene graph expressed in templates rather than in imperative Three.js calls. Do not adopt it if you need a framework-agnostic renderer, or if you are not prepared to track Three.js releases yourself. Before committing, install @tresjs/core, render one mesh, and confirm that the Three.js version it pulls in matches the one your other 3D code expects.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Tresjs/tres on GitHub