Rust/UI and the copy-paste component model borrowed from shadcn

Not a crate: the components are copied into your project

The central decision in Rust/UI is stated in the project guide without hedging. Rust/UI is not a component library you install as a crate. It is a collection of reusable components that you copy into your Dioxus applications.

The workflow is concrete. You browse the registry at rust-ui.com, find a component, and copy its source into your project's components/ directory. That is the whole installation step, and it is why the guide points you at the website for install commands rather than giving a cargo add line.

The arguments for this model are the ones shadcn made popular: full control, because the code is yours, and no version negotiation, because there is no dependency to upgrade. The costs follow equally directly. You maintain a fork of every component you copy, upstream fixes arrive as diffs you apply by hand, and there is no release train telling you what changed.

A registry is therefore a distribution channel rather than a package. That distinction matters for anyone assessing the project, because the maturity of the registry and the maturity of any single component are separate questions.

The stack is Dioxus 0.7, Tailwind v4, tw_merge and Lucide icons

The stack table is short and pins the versions that matter. Dioxus 0.7 is the fullstack Rust UI framework, Tailwind CSS v4 handles styling, tw_merge does Tailwind class merging, and the icons crate provides Lucide icons for Dioxus.

The tailwindcss dependency in package.json is at ^4.1.13 with @tailwindcss/cli at the same range, and tw-animate-css at ^1.4.0, which is the animation utility set Tailwind v4 projects typically pull alongside it. The npm side is therefore not optional: Tailwind is a build-time dependency of the component source itself, not an optional extra.

The Rust side pins Dioxus precisely. Cargo.toml specifies dioxus with version =0.7.9 and features router and fullstack, and dioxus-html at the same exact version, with a comment explaining the pin: dioxus 0.7.10 requires dioxus-desktop 0.7.10, which was unavailable on crates.io, and the desktop target had skipped straight to 0.8.0-alpha.

That comment is a good indicator of how the project handles dependency reality. Rather than moving to a version with a broken desktop story, it holds the last consistent set and records why.

Running it locally needs a Tailwind watcher, and dx serve starts it

The development setup is where the cross-language nature of the project becomes concrete. The guide asks you to clone the repository, install JavaScript dependencies, then start Dioxus:

git clone https://github.com/rust-ui/dioxus-ui.git
cd dioxus-ui
pnpm install
dx serve

The important line is the last one. dx serve automatically starts the Tailwind watcher and generates assets/tailwind.css from the root tailwind.css file, so no second CSS process is needed.

That single-command behaviour is not the default for a Dioxus project, and it is visible in the repository layout. package.json exposes a css script that runs tailwindcss with a watch flag and outputs to assets/tailwind.css, plus a css:build variant that minifies instead of watching, and a knip script for unused dependency checking. The justfile holds a dev target that runs the css script in the background alongside dx serve, which is the manual equivalent of what the integrated command does.

The platform targets are the usual Dioxus set:

dx serve --web --fullstack
dx serve --platform desktop
dx serve --platform ios

The web and fullstack mode is the one that matches the Docker image, which builds with dx build --release --fullstack and serves the resulting binary on port 8080.

The Docker image is a four stage musl build ending in distroless

The Dockerfile is a good place to see how the project expects to ship. It is a multi-stage build with four named stages.

The chef stage starts from messense/rust-musl-cross:x86_64-musl and installs cargo-binstall, then cargo-chef, then the build dependencies libssl-dev and pkg-config, and installs dioxus-cli locked for the x86_64-unknown-linux-gnu target before adding the wasm32-unknown-unknown target. The planner stage copies the source and runs cargo chef prepare to produce recipe.json. The builder stage runs cargo chef cook in release mode for x86_64-unknown-linux-musl, copies the full source, sets the musl linker environment variable, and runs dx build --release --fullstack.

The final cleaner stage is gcr.io/distroless/cc-debian12, and it copies only two things: the release web server binary as /server and the release web public directory as /public. The container sets IP to 0.0.0.0, PORT to 8080, exposes 8080, and runs /server.

The result is a minimal runtime image with no shell and no package manager, which is the right shape for a deployed service. The cost is that the image assumes a Linux x86-64 musl target, so a container built this way is not the path for an iOS or Android artefact.

iOS simulator scripts encode a painful detail into helper scripts

Running on the iOS simulator has a helper script per device, and the reason is spelled out in the guide. dx serve --platform ios targets whatever simulator is currently booted. To pick a specific device you use one of the scripts, and each of them shuts down other simulators, boots the right one, uninstalls the old build, then runs dx serve.

./run_ios_dioxus.sh       # uses whatever simulator is already booted
./run_ios_iphone_pro.sh   # boots iPhone 16 Pro (18.6)
./run_ios_ipad_pro.sh     # boots iPad Pro (12.9-inch, 3rd gen)

That sequence exists because the stale-build problem is real on the iOS simulator: an old binary is still installed, the simulator state is unpredictable, and a plain dx serve leaves you debugging the wrong artefact. The scripts encode the fix rather than leaving it as folklore.

The justfile has a matching ios target that opens the Simulator application and then runs dx serve --platform ios, so the workflow is available both through the helper scripts and through the task runner.

The scripts also pin specific hardware and OS versions in their comments, which means they are the most brittle part of the setup and will need editing when the simulator list changes.

A second framework directory next to the Dioxus components

The repository root contains a directory named leptos-ui alongside the Dioxus sources, and the topic list includes both axum and leptos. A Dioxus fullstack application commonly uses axum as its server layer, so axum on its own proves little.

What the leptos-ui directory suggests is a framework migration in progress: a second set of components for a different Rust UI framework sitting next to the existing Dioxus ones in the same tree. The guide does not explain the split, and it does not describe a Leptos setup, so this remains inference from the directory name and the topic tags rather than something the documentation states.

For an engineer evaluating the project, the practical consequence is a question to ask before committing. If you intend to build on Leptos, the components you would copy live in a directory whose workflow is undocumented here. If you are on Dioxus, the guides cover you well, but you should expect the balance to shift as the project continues.

The rest of the tree shows a much larger project than a component registry looks like. There are app_crates/ for internal crates such as registry, app_config and app_routes, an e2e/ directory, ios/ native files, style/, plans/, a Dockerfile, docker-compose.shared-server.yml, a .mcp.json, a justfile, deny.toml for dependency policy, clippy.toml, a rustfmt.toml, a rust-toolchain.toml, biome.json for JavaScript formatting and knip.json.

Hooks, formatting and the experiment warning

The guide treats repository hygiene as part of the workflow. Git hooks are enabled by pointing core.hooksPath at .githooks:

git config core.hooksPath .githooks

The pre-commit hook needs typos-cli and the nightly rustfmt component, and the project is explicit about the split, with the build toolchain staying stable and only formatting using nightly:

cargo install typos-cli
rustup toolchain install nightly --profile minimal --component rustfmt

That is a reasonable split, since rustfmt output can differ between channels and using nightly formatting only inside a pre-commit hook avoids churn in the stable build. The cost is that a contributor needs two toolchains installed.

The larger point is the status warning at the top of the guide, which says in plain terms that the project is early stage and experimental, that breaking changes are expected, and that contributors are welcome. It also states that the project is not affiliated with or endorsed by the Dioxus team and is an independent personal project, and asks contributors to read CONTRIBUTING.md before opening an issue.

The licence is MIT, the repository is not archived, and the last push was on 2026-10-18. There are no GitHub releases, so the registry is consumed from the website rather than from a versioned artefact.

Editorial conclusion

Rust/UI suits a team building a Dioxus fullstack application that wants Tailwind styled, type safe components without a versioned dependency to track, and that is comfortable owning the source of its own UI layer. It does not suit a project that wants a supported, semver-versioned component crate, because the copy-paste model gives you a copy with no upgrade path, and it does not suit anyone who needs stability today, since the project labels itself early stage and experimental with breaking changes expected. Before you build on it, look at the leptos-ui directory in the repository root alongside the Dioxus components, because that split suggests a framework migration under way, and check the pinned dioxus =0.7.9 dependency, which carries a comment explaining that 0.7.10 could not be used because the matching desktop crate was unavailable on crates.io.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rust-ui/ui on GitHub