rui: Rust UI library with GPU rendering and no retained view tree

rui is experimental and intended for a future version of Audulus, not general production use

Few UI library READMEs open with a self-assessment this candid. rui describes itself as an experimental Rust UI library and adds that it is in early days, while noting that some features already work. The stated long-term goal is to power a future version of Audulus, an audio synthesis application. An engineer looking for a stable foundation for a shipping product should read that as a clear boundary.

Version 0.6.1 is what Cargo.toml carries. No GitHub releases exist in the repository, meaning there are no tagged versions to pin, no release notes to consult and no changelog beyond what the commit history provides. The current project description in Cargo.toml echoes the README: 'Experimental Declarative UI library'. A Discord server is the primary community channel at https://discord.gg/JCVVBU3sCN.

Platform coverage for the core library is macOS, Windows and Linux. iOS support lives in a separate repository at https://github.com/audulus/rui-ios, and wasm is marked as WIP in the README. Any application targeting wasm or iOS has extra setup ahead that is not fully documented in this repository.

wgpu 0.20.0 and vger 0.3 replace DOM diffing: the full view re-renders on every state change

rui sits on two rendering libraries. wgpu provides the GPU backend at version 0.20.0, and vger provides 2D vector graphics at version 0.3. Geometry types come from euclid at version 0.22.7. All three are direct dependencies in Cargo.toml.

The architecture departs from most UI toolkits at one specific point: there is no retained view tree and no view diffing. Standard toolkits build a tree of objects representing the interface, compute differences between old and new trees, and apply minimal patches to the screen. rui does none of that. Every state change triggers a full re-render of the view.

Layout is an exception. rui caches layout and recomputes it only when state changes, which distinguishes it from pure immediate-mode systems that compute layout on every frame and are constrained to simpler layouts as a result. For an application like Audulus with per-view animation state changing frequently, layout recomputation is triggered only on central document state changes, not on local animation state, per the project's own design rationale. For a different kind of application that updates state very frequently across many views, that architecture is worth profiling before committing to it.

cargo run --example counter demonstrates the state function and vstack layout model

Running the counter example shows the core API. From the repository root:

cargo run --example counter

The counter source from the README uses a `state` function that takes two closures: one producing the initial value and one producing the view given the current state and a context:

use rui::*;

fn main() {
    state(
        || 1,
        |count, cx| {
            vstack((
                cx[count].padding(Auto),
                button("increment", move |cx| {
                    cx[count] += 1;
                })
                .padding(Auto),
            ))
        },
    )
    .run()
}

`cx[count]` reads the current state value using an index into the context. Mutation follows the same pattern: `cx[count] += 1`. Both the state display and the button use `.padding(Auto)` for spacing. Every example in the repository ends with `.run()` on the top-level view, which starts the event loop.

The winit feature, enabled by default in Cargo.toml, handles windowing. For embedding scenarios such as rui-ios, the feature is disabled with `default-features = false`. The README points to the rui-ios repository as the reference for that path.

canvas exposes the vger API directly for GPU drawing, with fill_circle and linear_gradient

Beyond standard widgets, rui provides a `canvas` primitive that calls into the vger library directly. The canvas example from the README shows how:

use rui::*;

fn main() {
    canvas(|_, rect, vger| {
        vger.translate(rect.center() - LocalPoint::zero());

        let paint = vger.linear_gradient(
            [-100.0, -100.0],
            [100.0, 100.0],
            AZURE_HIGHLIGHT,
            RED_HIGHLIGHT,
            0.0,
        );

        let radius = 100.0;
        vger.fill_circle(LocalPoint::zero(), radius, paint);
    })
    .run()
}

The callback receives the bounding rectangle and a vger context. `vger.translate` positions the coordinate system at the rectangle's center. `vger.linear_gradient` builds a paint from two endpoints, two colors and an opacity value. `fill_circle` draws a filled circle at the given center and radius. Color constants like `AZURE_HIGHLIGHT` and `RED_HIGHLIGHT` come from `use rui::*` and need no separate import.

For widgets above this level, the examples folder includes shapes (circle with `.color(RED_HIGHLIGHT)`, rectangle with `.corner_radius(5.0)`), an hslider with `.thumb_color(RED_HIGHLIGHT)`, a font_size modifier and a `Binding<f32>` pattern for connecting a component to a slice of state. Each is a separate .rs file in examples/.

rui explicitly avoids what SwiftUI does: texture caching, opaque machinery and C++ internals

SwiftUI is both the stated inspiration and the reference point for what rui chose not to do. A detailed rationale appears in the Why and how section of the repository. SwiftUI has a lot of machinery dealing with the caching aspects of things, described in the README as opaque and scary, occasionally crashing, with parts implemented in C++ rather than Swift. Testing for large node graphs showed it could not handle them well, which is the problem Audulus needed to solve.

The specific design decision that follows from that assessment is to skip texture caching entirely. Before programmable shaders, caching parts of a UI in textures was necessary for performance. CoreAnimation is cited as an example of this approach. With modern GPUs, the README argues that 2D UI graphics are a trivial workload, making that caching unnecessary and potentially counterproductive when enough of the interface is animating and caches need updating constantly. The memory cost for an unbounded node graph would also be unbounded.

rui's bet, in practical terms, is that full re-rendering on state change costs less than cache management. That holds as long as the view tree stays below the point where re-rendering becomes visible. No measurement from the repository demonstrates where that point is for a given hardware configuration, so Audulus's experience with its own node graphs is the only concrete evidence cited.

No unsafe and no RefCell are explicit design requirements, not just current practice

Two of the goals listed in the README stand apart from typical library promises. No use of `unsafe` and no use of `RefCell` are both listed as explicit requirements, which means they are design decisions rather than descriptions of the current state.

`RefCell` provides interior mutability with runtime borrow checking rather than compile-time borrow checking. Libraries that use it can express shared mutable state more freely, but the trade-off is runtime panics when the borrowing rules are violated. Excluding `RefCell` means rui enforces borrow rules at compile time across its codebase. A caller that encounters a borrow error gets a compile failure rather than a runtime panic in a deployed application.

Accessibility is also in the goals list. Cargo.toml includes accesskit at version 0.16.0 as a direct dependency, which is the library used for accessibility tree integration with assistive technologies. How complete that integration is at version 0.6.1 is not described in the README, and the wasm-specific dependencies include console_error_panic_hook at version 0.1.6 and console_log at version 1, showing active work on the wasm target even though the README marks it as WIP.

wasm support marked WIP, iOS via rui-ios, and last push on 2026-05-22 with no GitHub releases

Platform coverage in the repository is straightforward: macOS, Windows and Linux are marked as working. iOS requires the separate rui-ios repository and the `default-features = false` configuration to disable winit. wasm is marked as work in progress with no timeline given.

The wasm-specific section of Cargo.toml confirms active development: wasm-bindgen at 0.2.76, web-sys at version 0.3.61 with a Location feature, console_log and console_error_panic_hook are all present behind the wasm32 target gate. None of that translates into a documented deployment path in the README. A developer targeting web browsers cannot find step-by-step wasm instructions here.

The last push was on 2026-05-22, roughly five months ago as of the time this was written. No GitHub releases exist, so version 0.6.1 in Cargo.toml is the only version reference available. Any downstream project that depends on rui from crates.io is pinning to a single version with no release history to consult. The licence is MIT, covering both the library code and any modifications, with the standard disclaimer of warranty that carries extra weight for a library the README itself describes as experimental.

Editorial conclusion

Use rui if you are building a Rust application wanting SwiftUI-style declarative ergonomics with GPU rendering and no retained view tree, and you can accept experimental status with no tagged release. Skip it if you need a stable API, a production support commitment or working wasm output. Before adopting, check the Discord server at https://discord.gg/JCVVBU3sCN for the current accessibility integration state: accesskit 0.16.0 is a direct dependency but its integration depth is not described anywhere in the README. The last push was on 2026-05-22, and version 0.6.1 in Cargo.toml has no corresponding GitHub release.

Frequently asked questions

Official sources

1. audulus/rui on GitHub
2. Issues
3. License: MIT
4. README