HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
emilk
egui
Rust2021–2026
emilk / egui

egui

egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native

Web DevelopmentGames & EmulationMobile & Desktop
Explore on GitHubRead Hacker News discussions
53Distinct people
64Mentions
1Explicit recommenders
32.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Here is my favorite Rust GUI library: https://github.com/emilk/egui There are many other nice Rust GUI libraries depending on your needs: https://www.areweguiyet.com/

thesuperbigfrog used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:01:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year64 dated mentions

Observed mentions: 2021-08-13 08:13:12 UTC to 2026-05-14 22:02:10 UTC.

0510152021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 16 mentions; 4 submissions, 12 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 15 mentions; 4 submissions, 11 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC514
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1019
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC16412
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC16214
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC15411
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

What Hacker News says

10 sources
virtualritz·Dec 14, 2022
My main counter argument would be that most of the tasks I do on macOS require/are better done full screen. And if you are on macOS doing any kind of design work, this is your mode of working. People using Photoshop or any 2D/3D DCC etc. You use all the screen space real estate on any number of screens you have. But even if I write code I run VSCode in full screen. If I have a dual screen setup I usually have one screen with two code editors, mini map & folders + terminal on screen two. But that's it. But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent -- macOS native window management is shite. One of the first things people that come from a *nix d
Read the rest
esktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager. But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node. I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1]. Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done. The best you can do is go with dialog AHI guidelines and these fall short for this sort of window. I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from. Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps. They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co. IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'. [1] https://github.com/emilk/egui/issues/88
In Rust: State of GUI, December 2022
emilern·Dec 8, 2022
egui is an easy-to-use immediate mode GUI for Rust, and I just released 0.20. It's a big release! There is now support for AccessKit (https://github.com/AccessKit/accesskit) which brings accessibility to egui (a first for an immediate mode GUI?). There is also better table support, nicer keyboard shortcut handling, better looking text in light mode (still not great, but better). See more in the changelog: https://github.com/emilk/egui/blob/master/CHANGELOG.md Try it out at www.egui.rs
In Egui 0.20 Released
juancampa·Dec 5, 2022
That's because egui uses an "immediate mode" approach: it's rendering everything from scratch every time something _might_ have changed (e.g. a mouse move could've trigged a hover effect). Whereas the DOM uses "retained mode": it continually modifies a representation of the layout (DOM elements) and re-renders when something _actually_ changes. You can click on the "Backend" button at the top, and "Mean CPU usage" will tell you how long it takes for each frame to be produced. It'll vary depending on how complex the layout is: e.g. how many windows are open. But, contrary to retained mode, it doesn't matter at all if everything is animating simultaneously. More about immediate vs. retained: https://github.com/emilk/egui#why-immediate-mode
In Egui commit: Implement accessibility APIs via AccessKit
alice-i-cecile·Apr 15, 2022
The largest "game" that I'm aware of is a piece of closed source CAD software [0]. They've been thrilled with the performance and ergonomics of the code, although they're relying on egui [1] for the UI. As to scale, they crunch absolutely absurd amounts of data, seem to have an impressive amount of functionality, and are regularly hiring new folks from the community onto their team. [0]: https://www.foresightmining.com/ [1]: https://github.com/emilk/egui
In Bevy 0.7: data oriented game engine built in Rust
mockery·Jan 28, 2022
Perhaps confusingly, the term "immediate mode GUI" usually describes an API style. NOT an implementation detail. It suggests a particular implementation, but in practice most nontrivial "immediate mode" GUI libraries (including egui [1] and the famous Dear-IMGUI [2] [3] ) retain some "shadow state" between frames. The existence or scope of that state is a (sometimes-leaky) implementation detail that shouldn't distract from the fact that the API presented is still "immediate mode." [1] https://github.com/emilk/egui#ids [2] https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-a... [3] https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...
In Prime Video Uses WebAssembly

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.