Glory

Reactive interfaces in Rust. One Widget contract, multiple rendering hosts.

Website · Documentation · Try the counter · CLI guide

---

Glory brings owned, fine-grained reactivity to browser interfaces, server-rendered HTML and native applications. Write widgets with Rust builders or the optional XML-like view! syntax, then select the rendering host in your application.

• State with a lifetime. Cage, Bond and Vary connect values to their consumers. Owners release bindings, callbacks and tasks when a widget retires.
• HTML where you want it. Raw elements compile to shared templates and dynamic slots. Higher-level widgets add typed control behavior through the same Widget interface.
• Hosts with clear boundaries. Browser DOM, SSR, Apace's native document engine and Wry's system WebView have documented capabilities and acceptance.
• Tools owned by your project. Build, run, watch, diagnose and bundle with a CLI pinned alongside your application dependencies.

Development preview: 0.6.1 is unpublished and includes breaking API changes. Rust 1.95+ is required. Source development uses sibling Glory, Apace, Takia and Wingy repositories; see engine setup and release readiness.

Start building

From an application directory beside the source repositories:

[dependencies]
glory = { path = "../glory/crates/glory", version = "=0.6.1", default-features = false }

Add the host features your application needs. web selects the browser host; ssr enables server rendering; hydrate enables browser adoption of SSR output. The host table covers native options.

A widget in ordinary Rust

use glory::prelude::*;

fn counter() -> impl Widget {
    widget(|scope| {
        let count = scope.cage(0_u64);
        row().fill((
            text().content(count.map(|value| format!("Count: {value}"))),
            button().label("Add").on(activate, move |_| {
                count.revise(|value| *value += 1);
            }),
        )).build(scope)
    })
}

fn main() -> Result {
    let app = App::memory();
    app.mount(counter())?;
    Ok(())
}

App::memory() runs the reference interpreter without a window. The cross-platform counter shows the browser, Apace and Wry entry points for a shared widget.

Or use the optional XML syntax

Enable features = ["dsl"] on the Glory dependency:

fn greeting() -> impl glory::Widget {
    glory::view! {
        <div>
            <span>"Hello, Glory"</span>
            <glory::ui::Button label="Save"/>
        </div>
    }
}

Raw HTML, typed widget tags and ordinary factories compose in one tree. Each, Show and Content handle keyed lists, conditional branches and child ranges. Both frontends use the same checked templates and ownership model; #[glory::component] generates a typed Widget builder. See the display guide and Widget DSL guide.

Run the example

From the Glory repository root, use the counter's project-local launcher. On macOS or a configured WSL host:

./examples/counter/bin/glory doctor
./examples/counter/bin/glory serve --platform web
./examples/counter/bin/glory run --platform desktop
./examples/counter/bin/glory run --platform desktop --bin counter-wry
./examples/counter/bin/glory bundle --platform web

On Windows, use ./examples/counter/bin/glory.ps1 with the same arguments. The launchers configure approved host caches before invoking Cargo; no global Glory CLI is required. First use resolves the private runner and installs the matching wasm-bindgen tool when needed.

The CLI also supports feature overrides, native application arguments, shell completion, JSON build plans and opt-in WASM optimization. See the CLI guide for setup and feature comparison for remaining gaps.

Choose a host

Target	Application features	Rendering path and scope
Browser	web or dsl	Incremental DOM updates, controlled input and browser event/frame handling.
SSR and hydration	ssr, hydrate; optional stream, resources	HTML snapshots, adoption and pull-driven progressive output. Salvo supplies HTTP integration.
Native document	apace; optional apace-raster, apace-shell, apace-accesskit	HTML/CSS document layout, CPU rendering, window host and accessibility bridge. Adapter guide.
System WebView	wry	Native Rust state and tasks with incremental IPC-driven HTML updates. Adapter guide.
Android and iOS	App-owned native hosts	Activity/UIKit entries, packaging and platform setup live in the mobile example.

Standard Widget hosts support mixed HTML/widget trees. The direct sparse glory::display::App is a browser-only entry point. CSS, input, accessibility and OS integration support vary by adapter; compilation alone does not establish platform acceptance. Device installation, store distribution and screen-reader speech remain separate verification tracks.

The HTML wire version is defined by FORMAT_VERSION. Apace's typed style support is defined separately by STYLE_PROFILE; these are independent contracts.

Build on the core

Area	What Glory provides	Start here
Reactive state	Owned state, derived values, field/collection projections and cancellable resources	Runtime and host guide
UI and large lists	Typed controls, keyed rows and bounded fixed/measured-height windows	API guide
Routing	Typed targets, nested outlets, retained layouts, history and SSR outcomes	Routing
Localization	Opt-in Fluent catalogs and reactive application-local language selection	i18n
Application widgets	Controls, forms, navigation, themes and specialized widgets built on Glory	Sapid

get() clones a value; use with(...) to borrow large data. Reactive reads track inside bindings, derived values and effects. A bare widget-build read is not a subscription. The runtime guide explains ownership, batching, resources, list identity, hydration and streaming in detail.

For production application builds, put release settings in the application's own workspace manifest; dependency profiles do not apply to consumers:

[profile.release]
strip = "symbols"

Develop and verify

The root runtime workspace, CLI and examples have separate checks. Lockfiles are prepared locally, ignored by Git and retained for --locked verification. Configure build/cache/temp storage for your host before direct Cargo commands.

# Windows
./scripts/check-semantic-ui.ps1
./scripts/check-semantic-ui.ps1 -Web

# macOS; configures /Volumes/Data/Caches/glory
./scripts/check-semantic-apple.sh

WSL uses the Linux check script with a verified D:-backed build root. Browser, native-window, IME, device and accessibility checks are separate gates; the implementation ledger records their scope and remaining work.

Explore further

• Documentation index — APIs, architecture and implementation guides.
• Runtime and host guide — state, widgets, lists, SSR and hydration.
• Semantic contract — events, queries, controls and adapter limits.
• Performance reports and WASM size analysis — measured workloads and reproducibility.
• Engine provenance and release instructions — source versions and publication requirements.

License

Apache-2.0. See NOTICE and licensing details for retained third-party notices.