10 ms·

I Switched from Flutter and Rust to Rust and Egui

251 points by jdiaz97 1y ago

deleted 1y ago
[deleted]
kjuulh 1y ago
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
strogonoff 1y ago
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.
- zigzag312 1y ago
  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 1y ago
    '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.
  - bunderbunder 1y ago
    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.
- Philpax 1y ago
  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.
  - troupo 1y ago
    > more of a problem with eschewing the web's native UI stack and rendering everything yourself. Because web's "native UI stack" is almost non-existent for actual UIs. This has started to turn for the better only very recently: https://open-ui.org/ https://open-ui.org/
- deleted 1y ago
  [deleted]
feverzsj 1y ago
I still prefer good old GUI frameworks with WYSIWYG designers.
- jeroenhd 1y ago
  I think Slint is getting pretty close to that these days: https://slint.dev/ 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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
merksoftworks 1y ago
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.
- Aeolun 1y ago
  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 1y ago
    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
    - baq 1y ago
      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 1y ago
        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.
    - 1y ago
wdroz 1y ago
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/ https://dioxuslabs.com/ [1] -- https://blazingboard.ch/ https://blazingboard.ch/ (not mobile friendly, sorry)
rubymamis 1y ago
Honestly, nothing beats QML for UI development. Such an underrated technology.
- baq 1y ago
  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.
- lazypenguin 1y ago
  QML is nice and the bridges project could bring it to more languages. https://slint.rs/ https://slint.rs/ Is similar but written in Rust although.
- mhast 1y ago
  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.
  - jcelerier 1y ago
    > 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-syntax https://www.qt.io/product/qt6/qml-book/ch04-qmlstart-qml-syn...
paldepind2 1y ago
> 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.
- doawoo 1y ago
  State management in flutter can be done in so many ways so I get why it could feel complex, we’ve used Hooks a lot and it simplified a ton of stuff. Can also go the whole BLOC route too. Having issues with setState means you’re doing something that’s an anti-pattern
  - IshKebab 1y ago
    Yeah I think the point is that you have to become a state management expert in Flutter... even if the end result is not very complex there are so many options and so many pitfalls you still have to do a ton of thinking and learning to get there. With egui you pretty much don't have to think about it at all.
airstrike 1y ago
I feel obliged to mention that iced is a fantastic Rust GUI library for more complex applications: https://iced.rs https://iced.rs
- ogoffart 1y ago
  Since others are sharing Rust GUI libraries, I’ll mention Slint [https://slint.rs 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.
  - mtndew4brkfst 1y ago
    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#licensing 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.
    - OskarS 1y ago
      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.
    - ogoffart 1y ago
      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.
jeden 1y ago
please compile Your egui program and check: valgrind --leak-check=full --show-reachable=yes --track-origins=yes -s ./your_program is memory leak?
blu3h4t 1y ago
I wonder what typescript golang compiler means for flutter and dart :)
- _benton 1y ago
  they're gonna rewrite the dart compiler in typescript
rossant 1y ago
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 1y ago
  Isn't that basically what VDOM is?
  - k__ 1y ago
    A virtual DOM is another indirection, so the opposite of what immediate mode tries to accomplish.
    - edflsafoiewq 1y ago
      Immediate mode only describes the interface.
      - k__ 1y ago
        Does it? I had the impression that the lack of double buffering would imply a more direct access, this the "immediate" in the name.
        oasisaimlessly 1y ago
        Yes, "immediate" refers just to the API. Source: [1] [1]: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradigm#half-of-a-definition https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...
- ar-nelson 1y ago
  I really like Mithril.js (https://mithril.js.org/ 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.
dark__paladin 1y ago
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?
- mgerdts 1y ago
  From https://github.com/emilk/egui?tab=readme-ov-file#non-goals https://github.com/emilk/egui?tab=readme-ov-file#non-goals Non-goals * Become the most powerful GUI library * Native looking interface
- ogoffart 1y ago
  Slint is aiming at having native looking widgets.
lazypenguin 1y ago
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.
- airstrike 1y ago
  iced now has hot reloading :tada: https://github.com/iced-rs/iced/pull/3000 https://github.com/iced-rs/iced/pull/3000
chaosprint 1y ago
have you tried tauri or dioxus?
newswangerd 1y ago
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.
- turtlebro 1y ago
  That's a perfectly fine approach, Protobuf strength is exactly these kind of use cases.
- the__alchemist 1y ago
  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.
- nu11ptr 1y ago
  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.
  - klabb3 1y ago
    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.
    - 1y ago
voat 1y ago
I've personally been really impressed with gpui from the Zed folks.
- eviks 1y ago
  Which features impressed you there?
butz 1y ago
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.
pizzalife 1y ago
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.
eviks 1y ago
> 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?
Animats 1y ago
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. [1] https://github.com/emilk/egui/issues/7059 https://github.com/emilk/egui/issues/7059
- piker 1y ago
  Hmm. It seems to me that one of the features of an immediate mode library is that if you don't call something, you won't suffer overhead consequences. If you aren't trying to align things in a manner that triggers the two-pass rendering, then you shouldn't be affected by the associated performance hit. I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors.
  - Animats 1y ago
    > I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors. To some extent, yes. Here's an example.[1] So many features have been added that the unit tests were taking too long. So tests were switched to use a faster allocator. That won't even compile for cross-compilation from Linux to Windows. Because tests won't run, chasing down other cross-compilation bugs got much harder.[2] This is the price of feature bloat. Core stuff is breaking and not getting fixed as cool features are bolted on. Currently, 799 open bugs. The technical debt is building up. [1] https://github.com/emilk/egui/issues/7033 https://github.com/emilk/egui/issues/7033 [2] https://github.com/emilk/egui/issues/6847 https://github.com/emilk/egui/issues/6847
debarshri 1y ago
TIL egui. Reminds me of java swings.
bit1993 1y ago
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.
- airstrike 1y ago
  iced is cross platform, there's even WASM support. lots of Rust crates are. mobile and desktop are not different platform but different devices altogether that warrant separate designs IMHO
  - bit1993 1y ago
    > iced is cross platform How well does it integrate with Androids APIs or even IOS, can I make a full blown app with it. I believe the main reason why people use FFI to interface Rust and Dart/Flutter for mobile development is because Rust does not have an Android/IOS framework with the higher level APIs it just has native APIs (fs, io..)
    - airstrike 1y ago
      iced targets all major desktop platforms, not mobile
somesun 1y ago
i think if use rust , the best is tauri + any frontend (just let ai write frontend)

251 points by jdiaz97 1y ago

deleted 1y ago

[deleted]

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

strogonoff 1y ago

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.

zigzag312 1y ago
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 1y ago
  '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.
- bunderbunder 1y ago
  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.
Philpax 1y ago
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.
- troupo 1y ago
  > more of a problem with eschewing the web's native UI stack and rendering everything yourself. Because web's "native UI stack" is almost non-existent for actual UIs. This has started to turn for the better only very recently: https://open-ui.org/ https://open-ui.org/
deleted 1y ago
[deleted]

feverzsj 1y ago

I still prefer good old GUI frameworks with WYSIWYG designers.

jeroenhd 1y ago
I think Slint is getting pretty close to that these days: https://slint.dev/ 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 1y ago
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 1y ago
  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 1y ago
    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 1y ago

merksoftworks 1y ago

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.

Aeolun 1y ago
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 1y ago
  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
  - baq 1y ago
    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 1y ago
      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.
  - 1y ago

wdroz 1y ago

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/ https://dioxuslabs.com/ [1] -- https://blazingboard.ch/ https://blazingboard.ch/ (not mobile friendly, sorry)

rubymamis 1y ago

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

baq 1y ago
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.
lazypenguin 1y ago
QML is nice and the bridges project could bring it to more languages. https://slint.rs/ https://slint.rs/ Is similar but written in Rust although.
mhast 1y ago
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.
- jcelerier 1y ago
  > 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-syntax https://www.qt.io/product/qt6/qml-book/ch04-qmlstart-qml-syn...

paldepind2 1y ago

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

doawoo 1y ago
State management in flutter can be done in so many ways so I get why it could feel complex, we’ve used Hooks a lot and it simplified a ton of stuff. Can also go the whole BLOC route too. Having issues with setState means you’re doing something that’s an anti-pattern
- IshKebab 1y ago
  Yeah I think the point is that you have to become a state management expert in Flutter... even if the end result is not very complex there are so many options and so many pitfalls you still have to do a ton of thinking and learning to get there. With egui you pretty much don't have to think about it at all.

airstrike 1y ago

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

ogoffart 1y ago
Since others are sharing Rust GUI libraries, I’ll mention Slint [https://slint.rs 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.
- mtndew4brkfst 1y ago
  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#licensing 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.
  - OskarS 1y ago
    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.
  - ogoffart 1y ago
    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.

jeden 1y ago

please compile Your egui program and check: valgrind --leak-check=full --show-reachable=yes --track-origins=yes -s ./your_program is memory leak?

blu3h4t 1y ago

I wonder what typescript golang compiler means for flutter and dart :)

_benton 1y ago
they're gonna rewrite the dart compiler in typescript

rossant 1y ago

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 1y ago
Isn't that basically what VDOM is?
- k__ 1y ago
  A virtual DOM is another indirection, so the opposite of what immediate mode tries to accomplish.
  - edflsafoiewq 1y ago
    Immediate mode only describes the interface.
    - k__ 1y ago
      Does it? I had the impression that the lack of double buffering would imply a more direct access, this the "immediate" in the name.
      - oasisaimlessly 1y ago
        Yes, "immediate" refers just to the API. Source: [1] [1]: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradigm#half-of-a-definition https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...
ar-nelson 1y ago
I really like Mithril.js (https://mithril.js.org/ 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.

dark__paladin 1y ago

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?

mgerdts 1y ago
From https://github.com/emilk/egui?tab=readme-ov-file#non-goals https://github.com/emilk/egui?tab=readme-ov-file#non-goals Non-goals * Become the most powerful GUI library * Native looking interface
ogoffart 1y ago
Slint is aiming at having native looking widgets.

lazypenguin 1y ago

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.

airstrike 1y ago
iced now has hot reloading :tada: https://github.com/iced-rs/iced/pull/3000 https://github.com/iced-rs/iced/pull/3000

chaosprint 1y ago

have you tried tauri or dioxus?

newswangerd 1y ago

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.

turtlebro 1y ago
That's a perfectly fine approach, Protobuf strength is exactly these kind of use cases.
the__alchemist 1y ago
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.
nu11ptr 1y ago
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.
- klabb3 1y ago
  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.
  - 1y ago

voat 1y ago

I've personally been really impressed with gpui from the Zed folks.

eviks 1y ago
Which features impressed you there?

butz 1y ago

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.

pizzalife 1y ago

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.

eviks 1y ago

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

Animats 1y ago

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. [1] https://github.com/emilk/egui/issues/7059 https://github.com/emilk/egui/issues/7059

piker 1y ago
Hmm. It seems to me that one of the features of an immediate mode library is that if you don't call something, you won't suffer overhead consequences. If you aren't trying to align things in a manner that triggers the two-pass rendering, then you shouldn't be affected by the associated performance hit. I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors.
- Animats 1y ago
  > I guess you worry that the feature creep dilutes the maintainers' focus, but opening it up to a broader audience might get access to more contributors. To some extent, yes. Here's an example.[1] So many features have been added that the unit tests were taking too long. So tests were switched to use a faster allocator. That won't even compile for cross-compilation from Linux to Windows. Because tests won't run, chasing down other cross-compilation bugs got much harder.[2] This is the price of feature bloat. Core stuff is breaking and not getting fixed as cool features are bolted on. Currently, 799 open bugs. The technical debt is building up. [1] https://github.com/emilk/egui/issues/7033 https://github.com/emilk/egui/issues/7033 [2] https://github.com/emilk/egui/issues/6847 https://github.com/emilk/egui/issues/6847

debarshri 1y ago

TIL egui. Reminds me of java swings.

bit1993 1y ago

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.

airstrike 1y ago
iced is cross platform, there's even WASM support. lots of Rust crates are. mobile and desktop are not different platform but different devices altogether that warrant separate designs IMHO
- bit1993 1y ago
  > iced is cross platform How well does it integrate with Androids APIs or even IOS, can I make a full blown app with it. I believe the main reason why people use FFI to interface Rust and Dart/Flutter for mobile development is because Rust does not have an Android/IOS framework with the higher level APIs it just has native APIs (fs, io..)
  - airstrike 1y ago
    iced targets all major desktop platforms, not mobile

somesun 1y ago

i think if use rust , the best is tauri + any frontend (just let ai write frontend)