slintcn brings shadcn-style component registries to Rust UI apps

A new Slint project is making a familiar web-era promise to Rust UI builders: stop treating components like a black box and start shipping them as source you own. Steve Kwon’s slintcn arrived in a GitHub discussion as a shadcn/ui-style component registry for native Slint apps, with a workflow built around copying UI files into an application repository, editing the .slint files directly, and, if needed, hosting a registry of your own.

That detail matters because Slint already leans hard into reusable, typed UI building blocks. Its docs say each .slint file can define one or several components, and those components build a tree of elements that can be reused across a project. Slint is also pitched as an open-source declarative GUI toolkit for Rust, C++, JavaScript, and Python, with Live Preview for fast iteration and a Rust runtime that fits in less than 300KiB of RAM. slintcn fits neatly into that model: it does not ask Rust teams to bolt on a giant runtime dependency just to get polished controls.

Instead, the registry copies source into the app. That is the core appeal for Rust developers who care about versioning, reviewability, and precise customization. A button, dialog, or form block can live in the same repo as the product code, where it can be patched, themed, and refactored like any other Rust-adjacent asset. For teams building desktop apps that need a specific visual identity, that approach can beat a traditional widget library that hides behavior behind an API and leaves styling to a theme layer.

The project is already past the concept stage. The slintcn repository advertises live docs, a live demo, an npm-based CLI, generated previews, a theme system, and a static registry that can be self-hosted. The catalog is also substantial: the discussion post described 36 UI primitives and 5 installable blocks, while the repository page lists 56 UI components and 8 installable blocks. Either way, this is no toy example. It is large enough to suggest a real path toward building native interfaces with a shadcn-style distribution model.

That model is borrowed directly from shadcn/ui, which describes itself as a code distribution platform rather than a traditional component library and provides its own registry instructions. slintcn applies that same logic to Slint’s native stack, where the components are .slint source files instead of React snippets. The Slint maintainer response was telling too: ogoffart praised the interface’s simplicity, pointed to missing property docs as a useful improvement, and highlighted future slots, component factories, and optionals as features that could make third-party libraries even richer. The argument now is not whether Rust desktop apps need better UI distribution. It is whether slintcn just showed one of the cleanest ways to do it.