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.
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.]
From what I've seen immediate mode seems suitable for less fancy UI requirements. If you want to start having a framework solve things like animations and such then you'll probably end up with some form of retained mode.
Over my years making UIs I've found most of the bugs you get is due to incorrect state handling in applications. Having a framework you use which is opinionated and helps you solve that is pretty nice. (If your UI requirements are such that you need it.)
I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.
I think the default behavior is to only re-render if the window is active/focused. You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention.
This can be problematic, e.g. some of the sensor interfaces I have, I want to always display correct data, even if not focused. So, I have to decide if I want to have old data shown in the background misleading users, or have a per penalty from constant renders. Or try something else to be clever. (Maybe have it update at a low rate if not focused? I think that's the move...)
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.
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.)
That's not true, it only re-renders if there's an input event or an animation running. This is very easy to see if you just put a `println!` in your UI logic.
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.
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.
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
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.)
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.
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.
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.
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.
Just shooting from the hip, it's a lot of work, but even more importantly it's running slightly counter to the core motive behind many immediate mode GUI toolkits, which is to be as minimalist and easy to work with as possible.
For my part I have some accessibility needs that typically aren't well supported by immediate mode GUIs. And my personal take is, this is 100% fine. If you're working on a thing where an immediate mode GUI toolkit is even a realistic option, you're probably also in a situation where it's exceedingly unlikely that making your hobby project or prototype or whatever harder to work on will cause a net increase in humanity's overall sense of wellbeing.
And if something comes up and you do end up needing to make changes for someone else's benefit, hey, good news, immediate mode GUIs are really, really easy to hack on.
'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'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.
I don't understand what you mean by frontend and backend when you mention ffi. Is this backend in a remote server or just on the same app?
I used proto buf with rust, I had a rust client that spoke to my flutter frontend via dbus. The rust client connected to my remote server via a web socket and all messages were wrapped in protobuf and sent as binary. Made everything a lot more concrete... But it basically forced me to build my own much shittier version of gRPC. Since, if the wan for your network was every killed the client was notified too late and you'd end up with missing messages if the network buffer got filled. We added a message id and acknowledgement process with sqlite backing up each message.
My music model is all Protobuf messages, which go from Dart/Flutter land to Kotlin/C/Swift/JS audio backends on target platforms. I also use Protobuf for saving and sharing. It’s been incredibly resilient and performant.
Hah yea. I just did a deep dive into protobufs and RPC for an embedded application. Left learning a lot, and with a headache. Part of it was because this was using heapless, and I got errors until I configured the generator to use the right Vec sizes.
Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.
Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.
> 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 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.
I really like Mithril.js (https://mithril.js.org/), which is, IMO, as close as it gets to web IMGUI. It looks a lot like React, but rendering happens manually, either on each event or with a manual m.redraw() call.
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.
I will forever harp on the idea that we really set web design back by putting so much focus on the HTML. Dreamweaver sites were not great, to be sure. But they had more creativity and design than the majority of what we seem to create nowadays.
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.
WYSIWYG doesn't necessarily mean you are limited to using some designer and can't edit code. It's enough (and better) to have a live preview, than a full designer. It just means you see live what the code does, at the point when you write it, not later when you run it.
When hand-writing XAML or similar, it's great to see the UI created live. Like editing markdown and seeing the preview, versus editing markdown and not seeing the preview.
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...
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?
Because it's much harder to do better design, so often over technological soft good things fall through the cracks.
Like, why aren't more big projects use accessibility as hot reloading if those are so great?
Or, a simple illustration to your reliability point - part of the reason the files are hard to read is because XML is an atrocious format. And also tools like VS aren't even smart to preserve user formatting, so you can't even manually make it easier to read. Why hasn't it been changed in so many years?
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 would add that a large part of the push away from it came from not having dedicated design and development teams. Is, I think, why industries such as gaming have stuck to a lot of these workflows. You have art designers creating the assets and hand them off to an integration team that will get them into the game. Tooling is specifically made to integrate the art and the program.
In the web, we seem to have tried to converge all of that tooling into the symbolic text. Works great when it can work. But it greatly limits what you can graphically do. And is largely why we don't design things graphically anymore.
On Android (and I'm pretty sure iOS) you have WYSIWYG editors for UI layouts for jetpack compose and flutter (and on iOS it would be Swift UI).
These all go direct to code instead of XML or some other extra layer of code.
What I would probably focus on is better integration with Figma and similar tools. Use that to do the WYSIWYG part and then generate corresponding code (possibly with LLMs).
The biggest limitation you tend to have in WYSWIG is that at some point you really need to have the true data the user sees to ensure everything looks good. That becomes a bigger hassle than coding the UI manually. (Particularly when doing multi-platform things.)
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 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.
I don't have too much experience in GUIs and I've been looking at iced and gpui recently for a new GUI application.
iced has some nice looking apps written using it, but they all seem "laggy" on my high-end Linux box somehow. I'm wondering if this is a limitation of the immediate mode GUIs, or something related to my system, or an issue in the apps?
For example, drag-and-drops or selecting text with mouse lag behind the mouse cursor.
I'm wondering if I'm not holding it right somehow?
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.
Anyone considering it will need to decide for themselves how to feel about it, but I think it's important to prospective users to highlight that the current licensing model for Slint requires either GPL3-compatible licensing of your work, advertising for Slint within your own software, or paying ongoing licensing fees and/or royalties.
I only mention this because those constraints are notably more restrictive than the vast majority of the Rust crate ecosystem.
I take no particular stance on whether this is a fair or good practice or about the technical suitability of Slint beyond this concern, I just think it's a hurdle for most people so they should be made aware early and often.
I really like this model of ”GPL3, but commercial licenses available”. Means you can have a sustainable business without sacrificing open source. I wish it was more widespread, the prevalence of extremely permissive licenses has led to so many enormous companies using open source without giving back.
We're building Slint as a business. It takes a lot of time and effort to maintain and improve it.
We're not looking to support users who want to use it in proprietary software and give absolutely nothing back, not even a small credit. That doesn’t feel like too much to ask. (Even the MIT license requires including a copyright notice.)
Honestly, it’s a bit sad that for some, using libraries for free isn't enough, they also expect to do so without even mentioning the project.
After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind.
Spreading your code over multiple languages means you now have a bunch new fun edge cases to deal with when things get stuck and don't update correctly. With everything in one language that means all debuggers and other tools work the same regardless of where in the app I'm debugging.
I've found it fascinating to see UI building come full circle. I started in code (C), then using various XML schemes and now back in code (Kotlin, Flutter, Swift). But a big part of why it's nice now is because C is a pretty horrid language for making modern applications.
> After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind.
this is completely unrelated to what QML is.
QML is a complete language which allows to build both the application logic and the layout, which extends javascript with native reactive data binding. QML+QtQuick is equivalent to Dart+Flutter, or JS+HTML+CSS+React for instance.
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.
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.]
From what I've seen immediate mode seems suitable for less fancy UI requirements. If you want to start having a framework solve things like animations and such then you'll probably end up with some form of retained mode.
Over my years making UIs I've found most of the bugs you get is due to incorrect state handling in applications. Having a framework you use which is opinionated and helps you solve that is pretty nice. (If your UI requirements are such that you need it.)
I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.
I'm also thinking of building a word processor so I'd be interested to see what you're working on if you fancy sharing?
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.
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
I think the default behavior is to only re-render if the window is active/focused. You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention.
This can be problematic, e.g. some of the sensor interfaces I have, I want to always display correct data, even if not focused. So, I have to decide if I want to have old data shown in the background misleading users, or have a per penalty from constant renders. Or try something else to be clever. (Maybe have it update at a low rate if not focused? I think that's the move...)
> You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention.
sounds analogous to manual memory management
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.
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.)
That's not true, it only re-renders if there's an input event or an animation running. This is very easy to see if you just put a `println!` in your UI logic.
This is also mentioned in the gui docs here https://github.com/emilk/egui#why-immediate-mode:
> egui only repaints when there is interaction (e.g. mouse movement) or an animation, so if your app is idle, no CPU is wasted.
There are two modes, reactive and continuous. You can switch between them here in the backend tab:
https://www.egui.rs/
Reactive mode is the one you are looking for.
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.
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.
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
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.)
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.
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.
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.
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.
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.
Just shooting from the hip, it's a lot of work, but even more importantly it's running slightly counter to the core motive behind many immediate mode GUI toolkits, which is to be as minimalist and easy to work with as possible.
For my part I have some accessibility needs that typically aren't well supported by immediate mode GUIs. And my personal take is, this is 100% fine. If you're working on a thing where an immediate mode GUI toolkit is even a realistic option, you're probably also in a situation where it's exceedingly unlikely that making your hobby project or prototype or whatever harder to work on will cause a net increase in humanity's overall sense of wellbeing.
And if something comes up and you do end up needing to make changes for someone else's benefit, hey, good news, immediate mode GUIs are really, really easy to hack on.
'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'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.
I don't understand what you mean by frontend and backend when you mention ffi. Is this backend in a remote server or just on the same app?
I used proto buf with rust, I had a rust client that spoke to my flutter frontend via dbus. The rust client connected to my remote server via a web socket and all messages were wrapped in protobuf and sent as binary. Made everything a lot more concrete... But it basically forced me to build my own much shittier version of gRPC. Since, if the wan for your network was every killed the client was notified too late and you'd end up with missing messages if the network buffer got filled. We added a message id and acknowledgement process with sqlite backing up each message.
I still have nightmares about why I built that.
This is what I did for BeatScratch! https://beatscratch.io
My music model is all Protobuf messages, which go from Dart/Flutter land to Kotlin/C/Swift/JS audio backends on target platforms. I also use Protobuf for saving and sharing. It’s been incredibly resilient and performant.
Hah yea. I just did a deep dive into protobufs and RPC for an embedded application. Left learning a lot, and with a headache. Part of it was because this was using heapless, and I got errors until I configured the generator to use the right Vec sizes.
Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.
Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges.
I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.
Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.
Why not ConnectRPC? It's basically gRPC but without all the strange requirements for exotic HTTP features.
I actually use this currently. Not nearly as many platforms, but you an always fallback to gRPC.
That's a perfectly fine approach, Protobuf strength is exactly these kind of use cases.
> 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.
iced now has hot reloading :tada:
https://github.com/iced-rs/iced/pull/3000
> 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?
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.
I really like Mithril.js (https://mithril.js.org/), which is, IMO, as close as it gets to web IMGUI. It looks a lot like React, but rendering happens manually, either on each event or with a manual m.redraw() call.
I think, similar to Preact, Mithril skips the VDOM, which makes it "more immediate" than React.
However, updating the DOM and then turning the DOM to an image (i.e., rendering it) still has an indirection that using canvas/webgl/etc. don't have.
Isn't that basically what VDOM is?
A virtual DOM is another indirection, so the opposite of what immediate mode tries to accomplish.
Immediate mode only describes the interface.
Does it?
I had the impression that the lack of double buffering would imply a more direct access, this the "immediate" in the name.
I still prefer good old GUI frameworks with WYSIWYG designers.
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.
I will forever harp on the idea that we really set web design back by putting so much focus on the HTML. Dreamweaver sites were not great, to be sure. But they had more creativity and design than the majority of what we seem to create nowadays.
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.
WYSIWYG doesn't necessarily mean you are limited to using some designer and can't edit code. It's enough (and better) to have a live preview, than a full designer. It just means you see live what the code does, at the point when you write it, not later when you run it.
When hand-writing XAML or similar, it's great to see the UI created live. Like editing markdown and seeing the preview, versus editing markdown and not seeing the preview.
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...
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?
Because it's much harder to do better design, so often over technological soft good things fall through the cracks.
Like, why aren't more big projects use accessibility as hot reloading if those are so great?
Or, a simple illustration to your reliability point - part of the reason the files are hard to read is because XML is an atrocious format. And also tools like VS aren't even smart to preserve user formatting, so you can't even manually make it easier to read. Why hasn't it been changed in so many years?
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.
Agreed with your general push here, I think.
I would add that a large part of the push away from it came from not having dedicated design and development teams. Is, I think, why industries such as gaming have stuck to a lot of these workflows. You have art designers creating the assets and hand them off to an integration team that will get them into the game. Tooling is specifically made to integrate the art and the program.
In the web, we seem to have tried to converge all of that tooling into the symbolic text. Works great when it can work. But it greatly limits what you can graphically do. And is largely why we don't design things graphically anymore.
On Android (and I'm pretty sure iOS) you have WYSIWYG editors for UI layouts for jetpack compose and flutter (and on iOS it would be Swift UI).
These all go direct to code instead of XML or some other extra layer of code.
What I would probably focus on is better integration with Figma and similar tools. Use that to do the WYSIWYG part and then generate corresponding code (possibly with LLMs).
The biggest limitation you tend to have in WYSWIG is that at some point you really need to have the true data the user sees to ensure everything looks good. That becomes a bigger hassle than coding the UI manually. (Particularly when doing multi-platform things.)
I tried FlutterFlow but found I actually preferred writing everything in code. Also LLMs are great for writing Flutter layouts.
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 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 feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications:
https://iced.rs
I don't have too much experience in GUIs and I've been looking at iced and gpui recently for a new GUI application.
iced has some nice looking apps written using it, but they all seem "laggy" on my high-end Linux box somehow. I'm wondering if this is a limitation of the immediate mode GUIs, or something related to my system, or an issue in the apps?
For example, drag-and-drops or selecting text with mouse lag behind the mouse cursor.
I'm wondering if I'm not holding it right somehow?
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.
Anyone considering it will need to decide for themselves how to feel about it, but I think it's important to prospective users to highlight that the current licensing model for Slint requires either GPL3-compatible licensing of your work, advertising for Slint within your own software, or paying ongoing licensing fees and/or royalties.
https://github.com/slint-ui/slint/blob/master/FAQ.md#licensi...
I only mention this because those constraints are notably more restrictive than the vast majority of the Rust crate ecosystem.
I take no particular stance on whether this is a fair or good practice or about the technical suitability of Slint beyond this concern, I just think it's a hurdle for most people so they should be made aware early and often.
I really like this model of ”GPL3, but commercial licenses available”. Means you can have a sustainable business without sacrificing open source. I wish it was more widespread, the prevalence of extremely permissive licenses has led to so many enormous companies using open source without giving back.
We're building Slint as a business. It takes a lot of time and effort to maintain and improve it. We're not looking to support users who want to use it in proprietary software and give absolutely nothing back, not even a small credit. That doesn’t feel like too much to ask. (Even the MIT license requires including a copyright notice.)
Honestly, it’s a bit sad that for some, using libraries for free isn't enough, they also expect to do so without even mentioning the project.
I love how y'all target embedded. I love EGUI for PC applications, but will try Slint next time I'm doing an embedded device that has a display.
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 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'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?
Slint is aiming at having native looking widgets.
From https://github.com/emilk/egui?tab=readme-ov-file#non-goals
Non-goals
* Become the most powerful GUI library
* Native looking interface
I've personally been really impressed with gpui from the Zed folks.
Which features impressed you there?
I wonder what typescript golang compiler means for flutter and dart :)
they're gonna rewrite the dart compiler in typescript
please compile Your egui program and check:
valgrind --leak-check=full --show-reachable=yes --track-origins=yes -s ./your_program
is memory leak?
have you tried tauri or dioxus?
Honestly, nothing beats QML for UI development. Such an underrated technology.
After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind.
Spreading your code over multiple languages means you now have a bunch new fun edge cases to deal with when things get stuck and don't update correctly. With everything in one language that means all debuggers and other tools work the same regardless of where in the app I'm debugging.
I've found it fascinating to see UI building come full circle. I started in code (C), then using various XML schemes and now back in code (Kotlin, Flutter, Swift). But a big part of why it's nice now is because C is a pretty horrid language for making modern applications.
> After being stuck in XML land for making UI for almost two decades I couldn't be happier to leave it behind.
this is completely unrelated to what QML is.
QML is a complete language which allows to build both the application logic and the layout, which extends javascript with native reactive data binding. QML+QtQuick is equivalent to Dart+Flutter, or JS+HTML+CSS+React for instance.
https://www.qt.io/product/qt6/qml-book/ch04-qmlstart-qml-syn...
QML is nice and the bridges project could bring it to more languages. https://slint.rs/ Is similar but written in Rust although.
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.