I also came to a similar endpoint when building out a fairy large GUI application using egui. While egui solves the "draw widgets" part of building out the application, inevitably I had to restructure my app entirely with a new architecture to make it maintainable. In many places the "immediate" nature of the GUI mutable editing the state was no longer an advantage. Not to mention that UI code I wrote 6 months ago became difficult to read, especially if there was advanced layout happening.

Ultimately I've boiled my choices down to:

- egui for practicality but you pay the price in architecture + styling

- iced for a nice architecture but you have to roll all your own widgets

- slint maybe one day once they make text rendering a higher priority but even then the architecture side is not solved for you either

- tauri/dioxus/electron if you're not a purist like me

- Rewind 20 years and use Qt/WPF/etc.

egui has served me well and is eagerly recommended in "what gui should I use" threads since it solves the widget problem well in an easy-to-use package. However, any sufficiently advanced application ends up needing a nice architecture to maintain development speed and enjoyment. I've found whether using egui/slint/fltk/etc. you end up having to roll your own system. When you start needing things like undo/redo you suspiciously start architecting something that smells like the elm architecture.

Iced is the only Rust toolkit that I track that solves the architecture part upfront. The message pattern is hugely powerful but it is hard to appreciate until you've really gotten in the weeds on larger applications. Once iced reaches a point where there is an advanced set of widgets available I suspect its popularity will rise accordingly.

As a comparison, one of the most successful desktop gui toolkit of all times (Qt Widgets) solved the architecture/widget duality long ago with the signal/slot system and advanced widgets like treeviews, datagrid, etc. Since then we must have had hundreds of "desktop" toolkits across all languages that can draw buttons and dropdowns but nobody has toppled the king yet for building advanced desktop GUIs (although there were a few close competitors in C# with WPF and Java with Swing they only solved the widget part in my opinion). I like to think iced can take this mantle one day, best of luck to them and congrats on the 0.14 release.

Based on this section, it will be interesting to see how this evolves. I've used HTMX a bunch but after stumbling on Datastar I've come to prefer it. Partially because I don't need something like alpine.js to get some frontend goodies but also because I've come to appreciate the power of SSE streaming morphable targets to the browser

For testing, I can do a large amount of testing in a VM for my game. Maybe not 100% and not full user testing but nothing beats running on the native hardware and alpha/beta with real users.

Also, since I can pass through hardware to my VM I can get quite good performance by passing through a physical GPU for example. This is possible and quite straightforward to do on a Linux host. I'm not sure if it's possible using Parallels.

However, these days it's possible pass-through hardware to your VM so I would be able to pass through a 2nd GPU to MacOS...if it would let me run it as a guest.

As a game developer, I have to literally purchase Apple hardware to test rather than being able to conveniently download a VM

Comments URL: https://news.ycombinator.com/item?id=44397119

Points: 2

# Comments: 1