Edit: egui is an immediate mode GUI library written in Rust. egui runs natively on , and on the web it is compiled to WebAssembly and rendered with WebGL or WebGPU. Everything you see is rendered as textured triangles. There is no DOM, HTML, JS or CSS. Just Rust.
Devs are constantly making the mistake of falling in love with immediate mode GUIs... because it's convenient for them, the developer. For the user, it's almost always a worse experience as things don't behave in the same way as the rest of the platform they're on.
egui is great for video game debug UI overlays and internal tools, and maybe some specialized graphical tools. Otherwise its quirks are too annoying for general purpose app usage. Sure, you banged out a UI quickly with it, at the expense of your users.
No, it’s fine. It’s the longer term DX that takes a hit. Anything other systems can do, immediate mode can do, because like those systems you can always cache across frames. The same can’t really be said for retained mode. We wrote some about it here: https://tritium.legal/blog/desktop
I clicked on that expecting to see something about the limitations of retained mode, but I didn't see anything. There's a claim about long term retained mode complexity, and a discussion about a winit bug...
* Right off the bat in the login screen, if you resize the window, it flickers
* I logged in. Double clicking the top part of the window doesn't maximize it, like I expect on basically all other windows. I'm using MacOS, btw
* Resizing the main home screen is also a flickery mess. Though I'll give credit, it's a fast flickery mess, because the official spotify app resizes like ass
* Okay, here's one more specific to egui and why I think its approach is not good outside of the app types I listed in my original comment: I type some text in the search bar. Let's say I want to highlight the last word after I've typed it, in order to delete it or type something else. On every other app on my system, I can hold Option + Shift + Left Arrow Key. Or perhaps Cmd + Arrow Keys to move the cursor to the start or end of the line. The egui app just doesn't work, because egui misses so many fine details about text manipulation on a given OS.
* In general, text handling just sucks
* Scrolling doesn't have the inertial bounce when it hits the ends of a scroll action
* It's very easy to create overlapping UI elements by resizing panels and/or the window itself.
Anyway, those are just some of the things from a few minutes of trying this specific app out.
In general, if it's an egui app, I already know there will be weird resizing glitches/flickers, a poor text editing experience, and it will typically not follow the platform's idioms and built-in gestures, scroll physics, behaviors, etc. In this case, the app is decent since it mostly just needs to play music, and you mercifully don't need to interact with it much when it comes to text and such.
But saying "It's a GUI like any other" is like saying "wonderbread is a bread like any other". Maybe it's a curse of knowledge? Similar things happen with coffee. One person says "tastes like coffee" while another can pick out individual flavor notes. Maybe I'm shouting into the void and no one gives a shit anymore, I dunno. But to me, these things matter and are a mark of quality.
If we have LLMs that can shit out whatever code now, why aren't people having them output truly "native" GUIs that use the UI framework of the OS so they can get all the expected behaviors by default?
This seems like more of a complaint about egui's choice to re-implement all the widgets from scratch than its choice to use an immediate mode API. The two are orthogonal. The IMGUI idea has its roots in a community of people that like implementing things from scratch, but you could implement it on top of native widgets if you wanted to.
The choice to re-implement native widgets from scratch is justifiable if the egui devs think they can do better than the native widgets do. It's also nearly required in practice if they want the toolkit to have consistent behavior across multiple platforms (something people have learned the hard way multiple times across multiple different UI libraries).
It's hard to get it right, but that's why the egui devs are writing a library: so that others can benefit from that hard work. Many of the things you pointed out are just bugs, and bugs can be fixed.
> but you could implement it on top of native widgets if you wanted to
Is there an immediate mode GUI API that uses native widgets? I don't think I've ever seen that but would be curious to try it out. Does it work well in practice? If it doesn't exist, then it's kind of a moot point, isn't it?
I sympathize with wanting "consistent behavior across multiple platforms", but that usually just results in "consistently kneecapped behavior across multiple platforms".
You should draw a distinction between “implementing the GUI” and “implementing OS behavior”. Flickering aside egui works mostly fine for the former; the latter falls apart on most non-browser-and-non-toolkit-wrapper approaches because people never stop to handle those things.
E.g your double click on title bar thing sounds less like egui to me and more like somewhere in the stack is missing an AppKit flag.
I was about to come here and say that egui is a terrible choice for web. Everything is rendered in a canvas, so accessibility and extensibility is thrown out of the window. Basic browser functions like pinch-zoom don't work, it has some very wonky visual bugs when resizing the window, interactions have a very noticeable delay, no browser extensions work with this.
This is really not a good solution for web apps, and if you're vibe coding your apps anyway, there isn't any reason not to have a native browser application.
It's the first time I've heard about egui. I'm currently working on a desktop app that uses Tauri, and I realized there's a Tauri plugin that connects the two:
in addition to what other comments pointed out, on the demo ( https://www.egui.rs/#demo ) if you have a sidebar open, there is an offset of approximately the sidebar's width (though not exactly) between the system's mouse pointer position and the web app
The demos are very good: https://www.egui.rs/#clock
Edit: egui is an immediate mode GUI library written in Rust. egui runs natively on , and on the web it is compiled to WebAssembly and rendered with WebGL or WebGPU. Everything you see is rendered as textured triangles. There is no DOM, HTML, JS or CSS. Just Rust.