I use Egui, in a game-type application.
I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time.
Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get things above or to the left to adjust. But originally, that didn't work. You pretty much had to lay out widgets down and to the right. This is fast and simple. Lots of stuff didn't work, such as scrolling text boxes with line wrap.
But users doing ordinary GUI work are demanding more and more layout features, and won't stop until they get browser level layout. Overhead is increasing.[1] This is a problem in Rust game land, which is tiny. At some point, someone may need to fork Egui and create Egui-lite.
Immediate mode GUIs are cool but it seems that accessibility support is somewhat lacking. In native frameworks you often get it for free, on the Web you can follow ARIA and get it for free, but with immediate mode GUIs it seems that it is always a bit of an afterthought. For example, it seems that egui supports AccessKit, but not when used on the Web. With Dear ImGui it seems worse, there is some effort in that direction but tickets about accessibility are open (this is based on a quick scan, I may be wrong).
I guess it makes sense since immediate mode focuses on speed and applications like games, but if only there was best of both worlds.
I've been doing something similar to this, except with go. In my case I have a flutter frontend and a go backend that's built using go mobile. Instead of trying to figure out how to make all of my go functions use data types that are supported by the various native frameworks, I've opted to use protobuf objects for every type that is shared between the frontend and backend. This way I can expose a single go function via the flutter FFI that takes in a binary array and then converts it to a protobuf object. This gives me a nice separation of concerns between my business logic and frontend while also providing easy to use objects for the front and backend.
Not sure that I'd recommend this approach to everyone. Protobuf code generation can be finicky to set up, but I'm doing it so that I can access go's rich array of libraries in my app.
> A quick Google search with "flutter setstate is not refreshing" reveals a struggle that you will face quite often when running Flutter. It sounds like an easy fix, but the nature of Flutter using a bunch of nested Widgets creates, naturally, lasagna code that makes it hard to reason about this.
Can you expand on this OP? I've never had problems with `setState` nor "lasagna code" in Flutter. From a quick search I mostly seem to find questions from people who are still learning Flutter and getting basic things wrong.
There’s a big advantage to having your whole application in one language. I’m not sure the experience of egui on mobile though but egui is great to use as a developer
Pros
- Solid widget set
- Easy to get started
- Less state management
- Easy to make custom widgets
- Active community and crates (e.g docking view, tables, etc.)
- Fast to build new Ui
Cons
- Harder to do layouts (has multipass and some flexbox crates but still hard and compile loop makes it slow to iterate)
- Bring your own architecture (no restrictions on how you build your app so easy to make spaghetti if you’re not careful)
Egui is currently my favorite Rust UI crate although Slint and iced are also interesting.
I still prefer good old GUI frameworks with WYSIWYG designers.
I actually wanted to ask you about this at our last meetup (Rust Aarhus), so nice to see it on hackernews. It did seem you switched away from flutter. ;)
How is shipping egui apps vs flutter. I'd imagine that especially shipping a rust integration with Flutter might be a bit of a pain
I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications:
I really like the immediate mode GUI (IMGUI) paradigm. The other day, I looked into whether any web-based IMGUI libraries existed. It seems that HTML and the DOM are designed so differently from IMGUI that such an approach doesn't really make sense, unfortunately, unless everything is rendered manually in a canvas, WebGL, or WebGPU, which brings its own set of challenges.
> That didn't happen, so the Flutter capabilities were very underused. > I didn't even make an effort to make it look good
Makes sense to use a primitive instrument to satisfy primitive needs, those eschewing a lot of extra complexity.
Though if some funding does fall through for better gui, isn't that a risk of having to do another switch?
The nice thing about Flutter is that its cross-platform, write once run anywhere, I use Rust for the back-end. Personally I try not to use FFI because it adds complexity and ugly code, tracking object pointers, I'd rather just write pure Dart code.
I also prefer the mental model of immediate mode, but when I played with Dioxus[0] for a rust fullstack hobby project[1], I was able to adapt.
I liked the DX with the tools and the `rsx!` macro. The use of `#[cfg(feature = "server")]` to define server-side code is interesting, it lets you keep a shared codebase for frontend and backend, while still controlling what gets compiled to WASM for the client.
[0] -- https://dioxuslabs.com/
[1] -- https://blazingboard.ch/ (not mobile friendly, sorry)
I wonder what is the difference between binary and libraries sizes for Flutter and egui. My guess would be about tenfold reduction in size on egui.
I like egui a lot, but I haven't figured out how to not get blurry fonts in macOS/windows. If anyone has a tip I'd appreciate it.
I'm not a UI dev but I have messed with Qt some. Does egui or some other rust framework the same native look that Qt does?
TIL egui. Reminds me of java swings.
I've personally been really impressed with gpui from the Zed folks.
I wonder what typescript golang compiler means for flutter and dart :)
please compile Your egui program and check:
valgrind --leak-check=full --show-reachable=yes --track-origins=yes -s ./your_program
is memory leak?
i think if use rust , the best is tauri + any frontend (just let ai write frontend)
have you tried tauri or dioxus?
Honestly, nothing beats QML for UI development. Such an underrated technology.
So egui is great for projects where the application runtime is short lived, or for overlays in longer lived projects. The visual equivalent of scripts, where you know you need a small amount of immediate visual feedback and tweaking parameters for it to be useful to the end user.
Flutter answers questions about more robust UI.
It's good that you chose the right tool for the job and more people should know that there are options. But fundamentally I'm most motivated by the possibility of a robust UI framework made from first principles to be as low friction as egui but with the accessibility, performance, and visual flexibility of stylable retained mode guis.
Raph Levien and the xilem project might be getting us closer.