Glory is a experimental rust web front framework modified from leptos.
- Without hoops and props.
- Without virtual DOM.
- SSR and hydrate.
Your can find examples in examples folder.
Online example: http://glory.rs:8000.
| Glory | Leptos | Dioxus | Sycamore | |
|---|---|---|---|---|
| Component surface | Rust builder pattern (div().class().on(click, ...)) |
view! macro (RSX-like) |
rsx! macro |
view! macro |
| State primitive | Cage<T> (mutable) / Bond<T> (derived) / Lotus<T> (read-only union) |
RwSignal / Memo |
Signal<T> (Copy, generational-box) / Memo |
Signal / Memo |
Copy state handles |
Cage<T> is Copy; Owner reclamation is still in progress |
depends on signal flavour | yes | yes |
| Update model | Fine-grained subscription per view; no VDOM | Fine-grained, no VDOM | VirtualDom + WriteMutations per renderer |
Fine-grained, no VDOM |
| Targets today | Browser (CSR), SSR (HTML / Salvo), desktop webview, mobile templates, experimental Blitz/native command consumer | Browser + SSR + Axum/Actix + hydrate | Web / Desktop (webview) / Native (Blitz) / SSR / LiveView / Fullstack | Browser + SSR + hydrate |
| Multi-platform path | Fine-grained widgets produce a command stream for non-browser backends; desktop is usable, mobile/native still need product hardening | SSR / hydrate / Axum first-class | One VDOM, many renderer crates | DOM and SSR backends |
| DSL / macro | Generated tag factories (generate_tags!), no JSX-like macro on purpose |
Yes (view!) |
Yes (rsx!) |
Yes (view!) |
When does Glory make sense?
- You want a small, readable framework you can fully understand top-to-bottom.
- You prefer plain Rust (builder API) over macros and a
view!DSL. - You need CSR + Salvo-flavoured SSR today, and want an experimental path to desktop/mobile/native that stays close to the same widget code.
When to pick something else?
- You need a polished desktop/mobile/native product pipeline today → Dioxus.
- You want the most polished SSR / streaming / Axum story right now → Leptos.
- You want minimal framework surface for a static-feeling SPA → Sycamore.
For API-oriented docs and runnable example commands, start with
docs/README.md. For a deeper architectural comparison
(especially against Dioxus), see
_report.md. The current maturity gap board lives in
_todos.md; _improve_todos.md is the previous 2026-06-11
baseline that this board supersedes. Contributor conventions live in
AGENTS.md.
Fullstack server-function notes, including process-local server state/cache
helpers and SSR preload handoff, live in
docs/fullstack.md.
Scoped-style usage lives in docs/styling.md.
Contributions are absolutely, positively welcome and encouraged! Contributions come in many forms. You could:
- Submit a feature request or bug report as an issue;
- Comment on issues that require feedback;
- Contribute code via pull requests;
- Publish Glory-related technical articles on blogs or technical platforms。
All pull requests are code reviewed and tested by the CI. Note that unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Salvo by you shall be dual licensed under the MIT License, without any additional terms or conditions.
Glory is an open source project. If you want to support Glory, you can ☕ buy a coffee here.
Glory is licensed under:
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
