ThreeUI Community: The Open-Core Machine Turning 3D UI into a Real Component System

The surprising thing about ThreeUI Community is not the shaders. It is the machinery around them. The public repo behaves like a storefront, but the source of truth lives behind the curtain, and a sync pipeline decides what becomes visible, routable, and installable.

The real product is the pipeline

This is an open-core setup with discipline. A private Pro codebase feeds a public community edition, and the community repo is continuously derived from it. That means the project is not just publishing components. It is manufacturing a public surface from a governed source tree.

That matters because the repo has to solve two jobs at once. It has to be useful to developers who want 3D UI components now, and it has to protect the boundary between public and paid assets. The sync script handles that tension by filtering restricted files, stripping premium fonts, and emitting a public source manifest.

Why this is a different kind of 3D library

ThreeUI is not trying to be another low-level helper layer for React Three Fiber. It is closer to a finished visual vocabulary. The components are the point, not just the primitives underneath them.

The distinction is simple. Drei gives you the bridge. Spline gives you the studio. ThreeUI gives you the finished room, plus the code that built it.

The catalog behaves like a product, not a docs page

The browsing experience is not decorative. The app uses custom route resolution, legacy slug mapping, lazy-loaded components, and metadata-driven catalog results so the site behaves like a searchable product surface. That is why the public repo feels alive instead of archival.

The routing layer matters more than it first appears. Legacy IDs still resolve. Renamed shaders still preserve discovery. That kind of continuity turns a fast-moving design catalog into something indexable, bookmarkable, and safe to evolve.

// The shape of the catalog tells the story.
// Components are lazy-loaded, then flattened into browseable results.

export const routes = {
  "thinking-button": lazy(() => import('./ThinkingButton')),
  "uploading-button": 'redirect-to-thinking-button',
};

const results = createCatalogResults(shaders, categories, tags);

The important part is not the syntax. It is the contract. Source, metadata, routes, and search results are all tied together, so documentation behavior is not bolted on after the fact.

The component system is built to survive Three.js churn

There are two durability tricks here. First, the package uses explicit subpath exports, so consumers can import one component without dragging in the entire catalog. Second, the repository pins different Three.js versions through aliases, which reduces breakage when scenes depend on a specific renderer era.

That is a serious choice for a visual library. 3D UI tends to rot when its dependencies drift. ThreeUI treats versioning like an asset, not an afterthought.

What it beats, and what it is not

ThreeUI is best understood by what it replaces in the workflow. Compared with low-level tooling, it gives you much more finished output. Compared with closed visual tools, it gives you source code, exports, and direct ownership.

That makes its niche unusually clear. It is not a general 3D engine, and it is not a visual toy. It is a component system for teams that want spatial interfaces to behave like ordinary product code.

The agent angle follows naturally. If a component ships as source, props, metadata, and a clean manifest, then a coding agent can retheme it, search it, and reuse it with far less guesswork than a screenshot-based workflow would allow.