hello_egui is a shelf of ready-made egui widgets, and it tells you which ones are ready

One workspace, sixteen crates, two maturity levels

hello_egui is not a single widget library. The repository is a Rust workspace with a crates/ directory holding a family of small libraries that all target egui, the immediate mode GUI toolkit. The root crate hello_egui is described in the README as a collection of reexports, meant for the case where you want most of the pieces at once.

The README sorts them into two groups, and the distinction is the most useful thing in the file. The mature group contains egui_dnd for drag and drop sorting, egui_flex for flexbox layout, egui_inbox for sending messages to egui UIs from other threads or async functions, egui_virtual_list for a flexible virtual scroll widget with dynamic heights, egui_infinite_scroll built on top of that virtual list, egui_router as a single page application router with transitions, egui_form for form validation, egui_pull_to_refresh, egui_suspense for loading, error and retry states, egui_thumbhash for placeholder images, and egui_material_icons.

The experimental group is smaller and messier. egui_animation is used internally by egui_dnd, egui_taffy was an experiment that another author turned into a proper crate, egui_webview is unreleased, perfect_cursors is a port of an unrelated project that happens to have an egui example, and hello_egui_utils holds shared utilities. The author states plainly that maturity varies and that experimental crates can be released on request if you open an issue.

The root Cargo.toml is a feature switchboard for twelve dependencies

Adding hello_egui to a project pulls in every crate in the family unless you say otherwise. That control lives in the feature table of the root Cargo.toml, and the default list is spelled out explicitly:

[features]
all = [
    "animation",
    "dnd",
    "flex",
    "form",
    "inbox",
    "infinite_scroll",
    "pull_to_refresh",
    "router",
    "suspense",
    "thumbhash",
    "virtual_list",
]
full = ["all", "async", "tokio"]

Each entry maps to an optional dependency of the same name, so `dnd = ["dep:egui_dnd"]` and the rest. The `all` feature turns on eleven of them, and `full` adds `async` and `tokio` on top. The `async` feature is itself a fan out, forwarding to the async support of egui_suspense, egui_infinite_scroll, egui_router and egui_inbox, and `tokio` forwards to the tokio support of egui_suspense and egui_infinite_scroll.

That structure is the interesting design decision here. A single dependency with named features is convenient when you genuinely want everything, and wasteful when you want one widget. The workspace dependencies all resolve through `{ workspace = true, optional = true }`, so the individual crates share one version definition inside the repository.

Getting a crate in: crates.io first, workspace second

The README does not give a cargo install or cargo add line, so the honest path is the one it names. Every mature crate is published on crates.io under its own name, for example egui_dnd, egui_flex and egui_virtual_list, and the README links each of them to its crates.io page. That means you add the crate you want by name to your own Cargo.toml, or depend on the umbrella crate and pick features from the table above.

The workspace itself is in the repository, with Cargo.toml at the root, a Cargo.lock, a rust-toolchain.toml and a rustfmt.toml, plus a src/ directory and a scripts/ directory. A fancy-example/ directory holds the example application that uses most of the crates, and the README links the same app as a live demo at lucasmerlin.github.io/hello_egui.

The published crates are the ones to depend on for real work. The root crate is stated to include only crates that have been released on crates.io, which is a useful boundary: adding hello_egui never pulls an unpublished experiment into your build. What it does pull in is a set of dependencies you did not ask for, which is the trade to weigh against the convenience of one import.

What the pieces actually cover in an egui app

Reading the crate list as a set of design decisions rather than as a feature list is more useful. egui_inbox exists because egui UIs are drawn on the UI thread while Rust code frequently wants to send a result back from a worker thread or an async function, and the README describes it as a simple utility for exactly that problem. egui_suspense tackles the same family of concerns on the display side, giving you loading, error and retry UIs while data is in flight.

egui_router is a single page application router with transitions, which is a substantial thing to add to an immediate mode toolkit that otherwise leaves navigation to you. egui_flex gives flexbox layout to egui, and egui_taffy is the abandoned attempt at the same idea using the taffy layout engine, which a different author later turned into its own crate.

For data heavy screens there are three related pieces: egui_virtual_list for virtual scrolling with dynamic heights and complex layouts, egui_infinite_scroll layered on top of it, and egui_pull_to_refresh for the gesture that reloads a list. The README notes egui_virtual_list is compatible with egui_dnd, so a sortable virtual list is an intended combination rather than an accident.

The experimental list is where the sharp edges are

egui_webview carries an explicit warning in the README. It is a WebView widget for egui based on wry, it is described as experimental and unreleased, and it states that it currently uses some unsafe code to get around Send and Sync limitations, so it probably has safety issues. That is the author telling you not to ship it without reading the source.

The rest of the experimental group is milder but still worth reading closely. egui_animation is experimental yet already published, and it is used internally by egui_dnd, which means the mature drag and drop crate depends on an experimental one. perfect_cursors is described as a port of Steve Ruiz's perfect cursors project, independent of egui, with an egui example attached. hello_egui_utils is a collection of utilities used by the other crates, so it is an internal dependency rather than a user facing feature.

The practical policy the README gives for anything not yet on crates.io is to open an issue and ask for a release. That is the mechanism by which experimental work becomes usable, and it also means the experimental list changes over time in ways you should track rather than assume.

Releases are frequent and the project is not archived

Maintenance here looks healthy by the only two measures available. The repository is not archived, and the last push was on 2026-10-19, two days before this review. The release list shows hello_egui-v0.14.0 published on 2026-10-19, hello_egui-v0.13.0 on 2026-08-06, and hello_egui-v0.11.0 on 2026-03-26, the last of those described as pairing hello_egui 0.11.0 with egui 0.34.

That egui version pairing is the upgrade cost to plan for. Each release of the umbrella crate is tied to an egui generation, and moving to a newer egui means moving to a newer hello_egui release at the same time, because the workspace resolves every sub crate against one egui version. The release notes at that point in the history, hello_egui 0.11.0 for egui 0.34, make the coupling explicit.

The tooling around releases is also visible in the repository: a CHANGELOG.md, a RELEASE.md describing the release process, and a release-plz.toml, which is the configuration for automated version bumping and changelog generation. That last file is a decent signal of how releases are driven, since release-plz derives versions and notes from conventional commit messages.

Where this collection stops and egui itself continues

egui itself ships widgets for the fundamentals: text input, buttons, combos, sliders, trees and the rest, all drawn immediately in a retained UI state you own. What hello_egui adds is the layer that egui deliberately leaves open, namely layout engines, navigation, data loading states, virtualised scrolling and drag reordering.

The difference in approach matters when you compare with writing these yourself. Building a virtual list from scratch means tracking item heights, mapping scroll offset to visible indices and handling dynamic content yourself. The egui_virtual_list crate exists to absorb that work, and it advertises support for dynamic heights and complex layouts plus compatibility with egui_dnd, which is a combination most projects would otherwise assemble piecemeal.

The same reasoning applies to routing. egui_router gives you a single page application router with transitions in a toolkit that otherwise gives you panels and windows and nothing resembling a URL. That is the difference between adopting a crate and rebuilding one: the crate supplies a routing model, the manual approach supplies only drawing primitives. The catch is the coupling described above, where each of these crates is versioned in step with egui and with each other.

Editorial conclusion

Adopt the individual crates rather than the umbrella if you only need one behaviour, since the root package pulls twelve feature branches by default and every one of them becomes your dependency tree to track. Do not adopt egui_webview for anything you cannot audit, because the README states it is unreleased and uses unsafe code to work around Send and Sync limits. Verify first that the crate you want is published on crates.io, that the egui version it targets matches your own, and that the experimental crates you plan to use have been released, since the author asks for an issue before publishing them.

Frequently asked questions

Official sources

1. License: MIT
2. lucasmerlin/hello_egui on GitHub
3. Project website
4. README
5. Releases