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.

• piker

  today at 10:09 AM

  Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React.

  [Edit: although the standard accessibility criticisms apply to my application; although that's more of an issue with my implementation than an indictment of immediate mode generally.]

• Aeolun

  today at 9:37 AM

  If your UI is fast enough, why not in complex UI’s either? I’d say it gives you good motivation to keep your UI handling code as fast as possible.

  • mort96

    today at 9:56 AM

    Doesn't egui always re-render? I like my idle apps to be doing nothing, I don't want them running their render loop in the background

    • user____name

      today at 10:05 AM

      Any quarter decent imgui implementation will idle when there's no input or active animations, and the renderer can generate dirty tiles or rects to unnecessary redrawing -- if it matters, gpus are ridiculously overpowered for drawing a bunch of rectangles. Ui logic is usually firmly in the microseconds realm.

      • pixelpoet

        today at 11:28 AM

        I really wish this were built into imgui as a first-class use case instead of requiring a hodgepodge mix of unofficial hacks.

        I recall the author posting an imgui update saying this will be an officially supported mode, but AFAIK it's still not the case. Otherwise I would be building all my applications with imgui going forward.

        Re-rendering the screen, even if it's fast, incurs a lot of memory bandwidth to draw everything and swap framebuffers etc. Not something you'd like to happen on mobile, in particular. Just because the waste is "small", doesn't mean it's acceptable.

      • mort96

        today at 10:11 AM

        I agree that this is not a necessary downside to immediate mode GUIs, but we're talking about egui specifically here. AFAIK, egui always redraws at some relatively high rate even when nothing is happening. (I'm having trouble finding documentation about what that rate is though.)

    • freefrog1234

      today at 10:18 AM

      By default it re-renders on each event. This isn't often on mobile apps, but moving a mouse across a desktop app triggers multiple vents. There is a function call to request a re-render if you want not to wait for an event.

      • mort96

        today at 10:25 AM

        So if it's just an idle visible application, does it not render at all because there are no events? Or am I right that there's some idle redrawing going on

        • Philpax

          today at 10:59 AM

          With eframe, it does not re-render when idle, no. You need to have another thread that forces it to redraw on your own schedule. It will also redraw when an event occurs (mouse movement, keyboard presses, interacting with the application in general.)

    • baq

      today at 10:00 AM

      do you run without a compositor? I get where you're coming from, but 'idle' can mean a lot of different things and redrawing the whole UI at 60hz is not necessarily 'not idle' nowadays.

      • mort96

        today at 10:05 AM

        I run with a compositor, which is exactly why it's so great for the application to just draw its window once and then the compositor has the window's contents as a texture. The compositor can do whatever it wants with that texture without involvement from the application.

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.

• edflsafoiewq

  today at 11:54 AM

  Isn't that basically what VDOM is?

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.

• Philpax

  today at 11:02 AM

  The lack of accessibility on the web is less an immediate mode problem and more of a problem with eschewing the web's native UI stack and rendering everything yourself. There are ways to signal to the browser what the content of your custom rendering is, but they very much do not come for free and require much more integration than AccessKit does on native.

• zigzag312

  today at 9:52 AM

  Is there any technical limitation that accessibility support is usually lacking in immediate mode GUIs? Or it's just a lot of work?

  Flutter, which does its own rendering of controls, needs to implement a lot of accessibility features by itself.

  • baq

    today at 9:59 AM

    'a lot of work' is probably an understatement. one of the reasons everybody embeds browsers nowadays is all the text rendering quirks (e.g. right-to-left) are solved - and some of it includes accessibility (like easy theming, scaling, aria, screen reader support, etc.) browsers spent a lot of resources to make this happen.

I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications:

https://iced.rs

• ogoffart

  today at 11:03 AM

  Since others are sharing Rust GUI libraries, I’ll mention Slint [https://slint.rs] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.

> 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.

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 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 still prefer good old GUI frameworks with WYSIWYG designers.

• jeroenhd

  today at 8:51 AM

  I think Slint is getting pretty close to that these days: https://slint.dev/

  No quick and easy drag&drop just yet, but IDE support for live preview rendering makes it come pretty close. I do long for the Visual Studio GUI design days, but things aren't as barebones anymore as they used to be in open source Rust land.

• jenadine

  today at 10:37 AM

  WYSIWYG designers seem convenient, but they're not that popular anymore for a reason. Writing UI in code is more flexible, easier to maintain, and works better as projects grow.

  • alerighi

    today at 10:57 AM

    In the end the WYSIWYG would produce an XML file that you can put under version control. All depends on the UI of the thing your are building, if what you are building only needs to be functional and nobody cares about the UI (that is always the case of internal use software, that needs to have a good UX but who cares if it has the Windows 95 style controls, like machine HMIs, ERP software, etc.) WYSIWYG (like Visual Studio) are good to write things fast and typically with a consistent layout. I mean, most companies are not building a videogame, and most people are still fine using things like AS/400, so...

    • jenadine

      today at 11:20 AM

      But those files are often hard to read and merge. If WYSIWYG really worked well, why aren't more big projects or popular frameworks using it? Why do you think it's become less popular over time?

      • mattmanser

        today at 11:46 AM

        Because editors stopped trying to do WYSIWYG. It's not that the demand isn't there. They stopped trying about the time monitors went from a couple of quite similar fixed widths of 600/768 to more. Then smart phones came along and really killed the WYSWIG editor. I worked with Silverlight for a year in the late 2000s, and even by then WYSWYG editors were struggling. You sorta still had some for flash and stuff. They were trying to bring back a WYSWIG editor for it (and for WPF in general after silverlight flopped). But it was pretty clunky still. There's a lot of hard problems about how you anchor elements, how things scale, that are much easier to express in code than in a properties panel.

        You can see the demand in the sheer number of WYSWYG editors for the web.

        But for development, basically all the big players stopped trying or died for other reasons. I just think no-one's got the will to try it.

        I think it could be a huge opportunity for someone. Right now, with AI coming to the fore in development, seems to be when it would become absolutely killer for less code orientated people making their own apps by adding/dragging controls around and telling an AI what each control should do. All without a programmer involved. The AI could even "solve" the hard problem of a good responsive WYSWYG editor by making assumptions of how the user probably wants the controls anchored.

        So I think that's the market we'll see a WYSWIG editor emerge again for.

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?

Honestly, nothing beats QML for UI development. Such an underrated technology.

• baq

  today at 10:03 AM

  I don't think it's underrated, it's just that everyone builds for the web nowadays and it isn't like they don't have good reasons.