Xilem

Xilem is an experimental reactive UI framework for Rust, built by the Linebender project. It borrows the lightweight-view, diffing-based architecture popularized by React, SwiftUI, and Elm, but applies it to a strongly-typed, 'static Rust application state instead of a dynamically typed one. Application logic is expressed as a single function that turns state into a tree of view values; Xilem diffs that tree against the previous one and applies the minimal set of updates to the underlying native widgets.

Under the hood, Xilem is a thin reactive layer on top of Masonry, a retained-mode widget toolkit developed alongside it in the same repository. Masonry in turn is built on Vello and wgpu for GPU-accelerated 2D rendering, Parley and Fontique for text layout, AccessKit for accessibility, and winit for windowing, giving Xilem apps native performance and platform integration without hand-rolled widget code.

What You Get

• A reactive view-tree API (flex, grid, button, image, portal, progress_bar, and more) for declaring native UIs as plain Rust functions
• Masonry, a retained widget toolkit with layout, event handling, and accessibility built in, usable independently of Xilem’s reactive layer
• GPU-accelerated rendering via Vello and wgpu, text shaping via Parley/Fontique, and OS accessibility integration via AccessKit
• An async-aware driver (built on tokio) for spawning background tasks and feeding results back into the view tree
• An alternate xilem_web backend that targets the DOM/WASM, letting the same reactive-core concepts apply outside native apps
• Around twenty runnable examples (to_do_mvc, calc, stopwatch, http_cats, multiple_windows, etc.) covering common app-building patterns

Common Use Cases

• Building native, GPU-rendered desktop applications in Rust without adopting a web-view/Electron-style stack
• Prototyping reactive, SwiftUI/Elm-style UI architectures in a systems language for performance-sensitive apps
• Building tooling and internal apps (e.g. debuggers, inspectors, dashboards) that need a native Rust UI with minimal boilerplate
• Experimenting with a shared reactive-core view model across both a native (Masonry) and web (xilem_web/WASM) target

Under The Hood

Architecture — The workspace is organized as a layered stack of crates: xilem_core implements the generic, backend-agnostic reactive view-diffing engine; masonry_core/masonry provide a retained widget tree with layout, event, and paint passes; masonry_winit wires that toolkit to a real window via winit and Vello/wgpu; and the top-level xilem crate (via xilem_masonry) glues the reactive core to the Masonry widget tree. xilem/src/app.rs defines the Xilem/driver type that owns the winit event loop and drives app_logic on each state change, src/driver.rs bridges an embedded tokio runtime for background task spawning, and src/window_view.rs/window_options.rs manage per-window state. This separation lets the same diffing algorithm target a second backend, xilem_web, which renders to the DOM/WASM instead of Masonry.

Tech Stack — A 28-member Cargo workspace on the 2024 edition (MSRV 1.92), with rendering via Vello (GPU vector graphics) and wgpu (GPU abstraction), text layout via Parley/Fontique, accessibility via AccessKit, windowing via winit 0.30, and an embedded tokio runtime (rt-multi-thread) for async work. Performance-sensitive code uses smallvec and hashbrown; input events are normalized through ui-events/ui-events-winit. The repo ships a Nix flake for reproducible dev environments and enforces clippy, rustfmt, taplo (TOML formatting), and a typo checker in CI.

Code Quality — Strict lint/format tooling (.clippy.toml, .rustfmt.toml, .taplo.toml, .typos.toml) is gated in CI across the whole workspace. Masonry carries dedicated test modules (masonry/tests, masonry/src/tests) covering widget behavior, though the top-level xilem crate itself has very few inline #[test] blocks — correctness there leans more on Masonry’s tests and on the roughly nineteen runnable examples exercising real usage patterns. Every source file carries a copyright/SPDX header, and the project documents an explicit MSRV policy.

API Design — The public API centers on a small set of composable view functions (flex_col, label, text_button, etc.) returning impl WidgetView<State>, so a full app can be expressed as one app_logic(&mut State) -> impl WidgetView<State> function — the README’s counter example is roughly ten lines. Naming deliberately mirrors SwiftUI/Elm/React conventions, and the crate-level rustdoc doubles as a tutorial with a complete example. The tradeoff is that consumers must internalize the reactive view-diffing model up front, and the project is explicitly alpha, so some APIs still churn across releases.