4 ms·

> (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Fle

by goku12 1y ago

> (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout) This is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine. Servo was widely known around when Rust debuted.

echelon 1y ago
Questions for the Rust UX experts: Is Dioxus (or Leptos) much more performant than Tauri/Electron? I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern. Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword. Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now? Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver. Iced also looks cool, but looks less featureful. Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs? If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?
- airstrike 1y ago
  I'm super biased in favor of iced. Yes, there are missing features (it's not even version 1.0 yet!) but I think the number is very small now and the solution is usually to fill in the gaps yourself—which is possible because iced is totally modular I've made a spreadsheet editor and a slideshow editor with it so "slimmed down photoshop" seems feasible although admittedly you will likely need to get deep into the renderer (possibly write your own renderer traits and there), but I suppose you're comfortable with that given your goal. If you're not allergic to Discord, come join us. It's a helpful, awesome tight community IMHO Link for the lazy: https://discord.gg/3xZJ65GAhd https://discord.gg/3xZJ65GAhd Project link: https://iced.rs https://iced.rs
  - Macha 1y ago
    No support for RTL or CJK text, IMEs, or accessibility tools leaves it pretty firmly in the "toy" category for me for now, sadly. This isn't meant to bash on the project specifically, basically the only tools that meet that criteria are platform native UIs, the web stack (including Electron), Qt and Flutter. AccessKit is promising to change that but I haven't checked in a while how it's going. I did see GTK looking into it as a cross platform option as GTK's accessibility support only works on the Linux desktop currently
    - airstrike 1y ago
      In that case, I'm happy to let you know your info is outdated. CJK/IME support has landed. https://github.com/iced-rs/iced/pull/2777 https://github.com/iced-rs/iced/pull/2777
      - echelon 1y ago
        すごい！Japanese is one of our localization targets, so this is amazing! I'm building a graphically heavy app, so two more questions: 1) Is iced appropriate for building a canvas-type drawing app with image inclusions? Right now we're using Konva.js and we'd be losing a tremendous amount of out of the box flexibility in porting to iced, but the performance wins would be a major selling point. 2) Can you include Bevy panes? We're also doing some 3D visualization, and we currently use Three.js. But we have a lot of Bevy experience too.
        airstrike 1y ago
        Awesome! Glad to hear that and I hope you do give it another try. 1. Yes but not necessarily a "resounding yes" because images right now are drawn on the top of each layer, so if you want to write on top of images you'll need to create different layers for each of them which is more expensive than not doing that. You may be OK with that for now (I am, for my slideshow editor), but there's pending work to be done there to remove the requirement of explicit layering and thus improve performance. 2. I'm not familiar enough with Bevy to opine. I know there's https://github.com/tasgon/bevy_iced https://github.com/tasgon/bevy_iced but I think that might do the opposite of what you want. Having said that, iced lets you write custom shaders so you can go as deep in the stack as you'd like for any 3D visualization. The caveat then being that you're implementing all that logic yourself, but there's no stopping you. Importantly, I think it's worth joining the Discord and asking around, seeing what people are building, trying the library, and pointing out where you think you need help. This helps the core team understand use cases better and in some ways guides development IMHO. I'm not part of the core team, so I could be wrong, but that's my perception.
- daniel_sim 1y ago
  Check out https://www.gpui.rs/ https://www.gpui.rs/ too
  - criticalfault 1y ago
    Does it use Vulkan exclusively?
- deleted 1y ago
  [deleted]
- nicoburns 1y ago
  > Is Dioxus (or Leptos) much more performant than Tauri/Electron? For now it's largely the same. Both Dioxus and Leptos render using Tauri (or a web browser). For Dioxus, a Blitz-based renderer (Dioxus Native ) is in development which will change the story slightly. I would suggest Iced if you're looking for efficient (I don't think it's any less featureful than any other Rust-based GUI). With honourable mentions for Slint and Vizia.
- jpc0 1y ago
  > I want to (1) build blindingly fast, low-latency, super performant UX for users, … (2) maintain developer velocity, (3) have access to nice UX primitives and widgets … (4) have it look nice and modern. Find me when you find this, because I actually think it is impossible. I think there is fundamentally too much inherent complexity to abstract away to keep 2 and not sacrifice 1. Specifically for something properly cross platform. If you are only targeting MacOS or windows then I think it’s absolutely possible but then you are using the wrong language, nothing against rust at all on that, the platform defaults are just swift / C# for those use cases. And I’m not sure but unless you are just using a gtk/Qt style framework you would absolutely run into a11y problems that you would need to build around yourself. Sounds like you probably want egui though… if your primary UI is a big canvas that needs to be hardware accelerated and interaction is just to assist that use case egui is probably a good bet for you. But you wouldn’t be hiring web devs to do that.
  - cosmic_cheese 1y ago
    I believe it’s possible, but it’s going to take a little bit of outside of the box thinking in that it’d be most practical if the UI toolkit isn’t bound strictly to a single paradigm. Both imperative and declarative UIs have serious problems. Imperative toolkits can get hairy with their boilerplate and can make staying in sync with data state a real challenge, while declarative toolkits have a strong tendency towards rigidity that makes for awkward DX and ugly code in all but the simplest todo app kind of examples and don’t lend themselves to fine grained control. I think there’s a happy medium to be found between the two in a well-designed hybrid. This hypothetical framework would allow full declarative in situations where that’s highly suitable, but would also allow the dev to do widget configuration in a more traditional imperative style or if necessary fall back to full imperative. Support for reactivity on both sides of the coin would be robust so staying in lockstep with data is simplified. This would bring down boilerplate substantially since the broader layout of most screens could be done declaratively, but it wouldn’t come at the cost of more advanced functionality, flexibility, and developer control on the individual widget level. I’d like to dig further into these ideas at some point if I get time.
    - 1y ago
- spease 1y ago
  Slint recently added Bevy support. I’ve been keeping an eye on it since I’ve used Qt and love working in Qml.
  - echelon 1y ago
    Slint cites Javascript. Is it another Electron/Tauri-like?
    - jenadine 1y ago
      Slint does not use a browser. Instead, it has its own runtime written in rust and uses a custom DSL to describe the UI. It has API for different programming language. For Javascript, it uses node or deno for the application logic, and then spawn the UI with its own runtime without the browser. In a way it is the opposite which took the JS runtime out of electron to replace it with a Rust API, while Slint keeps the JS runtime but swaps the browser for its own runtime (for the JS dev point of view)
    - Narishma 1y ago
      No, it's like Qt and QML.
    - Ygg2 1y ago
      What?! No. It's Rust GUI toolkit. I swear people see JS support and think Electron.
- rollcat 1y ago
  I'm no UX expert, but I regularly try out new (and old) toolkits to understand the problem space. It really sounds like you want an immediate mode toolkit. Retained mode will never be "super-snappy", there's an entire sandwich between your code and the pixels. Look at Blender or Reaper, this is the kind of "feel" you'd be getting. If you want retained mode + "true" native widgets on all platforms, investigate: Toga (Python), WxWidgets (C++), and Tk (Tcl). The native toolkits are often best in class on each platform, and these wrappers are about as thin as they can reasonably get (e.g. Toga uses pyobjc). Integration with Rust is left as an exercise to the reader ;) A rich widget library is nice, but consider the depth as well. Egui went to great lengths to integrate assistive technologies, which depending on your target audience may be impactful. (Also: accessibility is for everyone. https://shortcat.app/ https://shortcat.app/) If you want easy hiring, you have to go with mainstream. We've +/- named all of the options by now. Otherwise, hire a talent who's worked on the next closest thing to what you're building, and trust them to decide the direction. Looks and beauty are in the eye of the beholder. There are many apps that have a distinct, sometimes quirky, but appreciable style. Reaper looks out of place on every platform, but I prefer it over Logic or Ableton.
- explodingwaffle 1y ago
  Certainly not a "Rust UX _expert_", but I do find GPUI interesting. Some nice examples here of not-"just text/button widget programs": https://github.com/longbridge/gpui-component https://github.com/longbridge/gpui-component
- usrusr 1y ago
  Makepad is neither gtk generation nor browser based. Might check the "just text/button widget" box though, I'd certainly place it on the minimalistic end of the spectrum. (haven't worked with makepad, just enjoyed the demo)
  - rapnie 1y ago
    Makepad [0] is indeed quite impressive. You can directly try Makepad Studio in your browser [1]. Don't know if that's the latest or the demo version. Their demo vids are a good watch. [0] https://makepad.nl https://makepad.nl [1] https://makepad.dev https://makepad.dev
- dceddia 1y ago
  I know it’s usually taken as a given around here that Electron is slow, and many of the big-name apps using it are cited as examples with good reason. From working on a Tauri app myself for a few years (video editor) I just think the blame is misattributed. These things are not inherently slow. Slower than native? Maybe, probably, at the level of milliseconds. Visibly laggy? No, that’s the badly-written UI code’s fault. (see also: the latest iterations of the macOS System Settings UI, where the search box lags like crazy) A webview can be extremely responsive. It won’t be if you treat it like a web page (where clicking buttons fires off HTTP requests) or if you let the JS framework code get out of hand, but those are not the fault of the wrapper. If you like building with HTML/CSS/JS then I’d recommend doing some perf experiments to see how far these tools can take you. Of course if you don’t want to use that stack then pick something else :) If you’re building photoshop, the main UI will probably be canvas anyway, where drawing is fully under your control, no matter which framework you go with. That stuff can be very fast or very not-fast depending on how the code is written.
nicoburns 1y ago
> this is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine It's certainly a newer and lesser-known engine. It's mostly been me working on it for the past year or so (with a couple of other occasional contributors). But I do have funding to work on it full time through DioxusLabs (who are building Dioxus Native - a Flutter / React Native competitor on top of it) and NLnet (who are a non-profit interested in the alternative web browser use case). We're trying to really push on the modular side of things to create a web engine that's flexible / hackable and can be moulded for a variety of use cases. We'd love more contributors, so if anyone is interested in getting involved then drop by our GitHub (https://github.com/DioxusLabs/blitz/ https://github.com/DioxusLabs/blitz/) or Discord (https://discord.gg/AnNPqT95pu https://discord.gg/AnNPqT95pu - #native channel)
- goku12 1y ago
  You have my admiration and support for this work! I guess it goes without saying how monumental and critical the work on alternative engines like servo and libweb are. We are genuinely tired of the current duopoly (I'm starting to lose hope with Firefox and gecko as well. They seem to have priorities different to our expectations.) But I guess we now have one more to look forward to, thanks to you and the rest of the team! Personally, I hope to pitch in as soon as I have some spare time available. Regards!
  - nicoburns 1y ago
    > You have my admiration and support for this work! Thanks! > Personally, I hope to pitch in as soon as I have some spare time available. Amazing - maybe see you around :)
- dingi 1y ago
  Just skimmed through the Blitz source. Really interesting. I don’t have experience with UI rendering or Rust, but I couldn’t help wondering: if you leave out things like local storage and websockets, why include networking at all? Feels like a separate concern. Genuinely curious. Great project. Wishing you all the best!
wodenokoto 1y ago
Wasn’t rust and servo co-developed?
- goku12 1y ago
  Yes. That's what I meant, in case my framing is confusing.

by goku12 1y ago

echelon 1y ago

Questions for the Rust UX experts: Is Dioxus (or Leptos) much more performant than Tauri/Electron? I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern. Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword. Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now? Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver. Iced also looks cool, but looks less featureful. Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs? If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?

airstrike 1y ago
I'm super biased in favor of iced. Yes, there are missing features (it's not even version 1.0 yet!) but I think the number is very small now and the solution is usually to fill in the gaps yourself—which is possible because iced is totally modular I've made a spreadsheet editor and a slideshow editor with it so "slimmed down photoshop" seems feasible although admittedly you will likely need to get deep into the renderer (possibly write your own renderer traits and there), but I suppose you're comfortable with that given your goal. If you're not allergic to Discord, come join us. It's a helpful, awesome tight community IMHO Link for the lazy: https://discord.gg/3xZJ65GAhd https://discord.gg/3xZJ65GAhd Project link: https://iced.rs https://iced.rs
- Macha 1y ago
  No support for RTL or CJK text, IMEs, or accessibility tools leaves it pretty firmly in the "toy" category for me for now, sadly. This isn't meant to bash on the project specifically, basically the only tools that meet that criteria are platform native UIs, the web stack (including Electron), Qt and Flutter. AccessKit is promising to change that but I haven't checked in a while how it's going. I did see GTK looking into it as a cross platform option as GTK's accessibility support only works on the Linux desktop currently
  - airstrike 1y ago
    In that case, I'm happy to let you know your info is outdated. CJK/IME support has landed. https://github.com/iced-rs/iced/pull/2777 https://github.com/iced-rs/iced/pull/2777
    - echelon 1y ago
      すごい！Japanese is one of our localization targets, so this is amazing! I'm building a graphically heavy app, so two more questions: 1) Is iced appropriate for building a canvas-type drawing app with image inclusions? Right now we're using Konva.js and we'd be losing a tremendous amount of out of the box flexibility in porting to iced, but the performance wins would be a major selling point. 2) Can you include Bevy panes? We're also doing some 3D visualization, and we currently use Three.js. But we have a lot of Bevy experience too.
      - airstrike 1y ago
        Awesome! Glad to hear that and I hope you do give it another try. 1. Yes but not necessarily a "resounding yes" because images right now are drawn on the top of each layer, so if you want to write on top of images you'll need to create different layers for each of them which is more expensive than not doing that. You may be OK with that for now (I am, for my slideshow editor), but there's pending work to be done there to remove the requirement of explicit layering and thus improve performance. 2. I'm not familiar enough with Bevy to opine. I know there's https://github.com/tasgon/bevy_iced https://github.com/tasgon/bevy_iced but I think that might do the opposite of what you want. Having said that, iced lets you write custom shaders so you can go as deep in the stack as you'd like for any 3D visualization. The caveat then being that you're implementing all that logic yourself, but there's no stopping you. Importantly, I think it's worth joining the Discord and asking around, seeing what people are building, trying the library, and pointing out where you think you need help. This helps the core team understand use cases better and in some ways guides development IMHO. I'm not part of the core team, so I could be wrong, but that's my perception.
daniel_sim 1y ago
Check out https://www.gpui.rs/ https://www.gpui.rs/ too
- criticalfault 1y ago
  Does it use Vulkan exclusively?
deleted 1y ago
[deleted]
nicoburns 1y ago
> Is Dioxus (or Leptos) much more performant than Tauri/Electron? For now it's largely the same. Both Dioxus and Leptos render using Tauri (or a web browser). For Dioxus, a Blitz-based renderer (Dioxus Native ) is in development which will change the story slightly. I would suggest Iced if you're looking for efficient (I don't think it's any less featureful than any other Rust-based GUI). With honourable mentions for Slint and Vizia.
jpc0 1y ago
> I want to (1) build blindingly fast, low-latency, super performant UX for users, … (2) maintain developer velocity, (3) have access to nice UX primitives and widgets … (4) have it look nice and modern. Find me when you find this, because I actually think it is impossible. I think there is fundamentally too much inherent complexity to abstract away to keep 2 and not sacrifice 1. Specifically for something properly cross platform. If you are only targeting MacOS or windows then I think it’s absolutely possible but then you are using the wrong language, nothing against rust at all on that, the platform defaults are just swift / C# for those use cases. And I’m not sure but unless you are just using a gtk/Qt style framework you would absolutely run into a11y problems that you would need to build around yourself. Sounds like you probably want egui though… if your primary UI is a big canvas that needs to be hardware accelerated and interaction is just to assist that use case egui is probably a good bet for you. But you wouldn’t be hiring web devs to do that.
- cosmic_cheese 1y ago
  I believe it’s possible, but it’s going to take a little bit of outside of the box thinking in that it’d be most practical if the UI toolkit isn’t bound strictly to a single paradigm. Both imperative and declarative UIs have serious problems. Imperative toolkits can get hairy with their boilerplate and can make staying in sync with data state a real challenge, while declarative toolkits have a strong tendency towards rigidity that makes for awkward DX and ugly code in all but the simplest todo app kind of examples and don’t lend themselves to fine grained control. I think there’s a happy medium to be found between the two in a well-designed hybrid. This hypothetical framework would allow full declarative in situations where that’s highly suitable, but would also allow the dev to do widget configuration in a more traditional imperative style or if necessary fall back to full imperative. Support for reactivity on both sides of the coin would be robust so staying in lockstep with data is simplified. This would bring down boilerplate substantially since the broader layout of most screens could be done declaratively, but it wouldn’t come at the cost of more advanced functionality, flexibility, and developer control on the individual widget level. I’d like to dig further into these ideas at some point if I get time.
  - 1y ago
spease 1y ago
Slint recently added Bevy support. I’ve been keeping an eye on it since I’ve used Qt and love working in Qml.
- echelon 1y ago
  Slint cites Javascript. Is it another Electron/Tauri-like?
  - jenadine 1y ago
    Slint does not use a browser. Instead, it has its own runtime written in rust and uses a custom DSL to describe the UI. It has API for different programming language. For Javascript, it uses node or deno for the application logic, and then spawn the UI with its own runtime without the browser. In a way it is the opposite which took the JS runtime out of electron to replace it with a Rust API, while Slint keeps the JS runtime but swaps the browser for its own runtime (for the JS dev point of view)
  - Narishma 1y ago
    No, it's like Qt and QML.
  - Ygg2 1y ago
    What?! No. It's Rust GUI toolkit. I swear people see JS support and think Electron.
rollcat 1y ago
I'm no UX expert, but I regularly try out new (and old) toolkits to understand the problem space. It really sounds like you want an immediate mode toolkit. Retained mode will never be "super-snappy", there's an entire sandwich between your code and the pixels. Look at Blender or Reaper, this is the kind of "feel" you'd be getting. If you want retained mode + "true" native widgets on all platforms, investigate: Toga (Python), WxWidgets (C++), and Tk (Tcl). The native toolkits are often best in class on each platform, and these wrappers are about as thin as they can reasonably get (e.g. Toga uses pyobjc). Integration with Rust is left as an exercise to the reader ;) A rich widget library is nice, but consider the depth as well. Egui went to great lengths to integrate assistive technologies, which depending on your target audience may be impactful. (Also: accessibility is for everyone. https://shortcat.app/ https://shortcat.app/) If you want easy hiring, you have to go with mainstream. We've +/- named all of the options by now. Otherwise, hire a talent who's worked on the next closest thing to what you're building, and trust them to decide the direction. Looks and beauty are in the eye of the beholder. There are many apps that have a distinct, sometimes quirky, but appreciable style. Reaper looks out of place on every platform, but I prefer it over Logic or Ableton.
explodingwaffle 1y ago
Certainly not a "Rust UX _expert_", but I do find GPUI interesting. Some nice examples here of not-"just text/button widget programs": https://github.com/longbridge/gpui-component https://github.com/longbridge/gpui-component
usrusr 1y ago
Makepad is neither gtk generation nor browser based. Might check the "just text/button widget" box though, I'd certainly place it on the minimalistic end of the spectrum. (haven't worked with makepad, just enjoyed the demo)
- rapnie 1y ago
  Makepad [0] is indeed quite impressive. You can directly try Makepad Studio in your browser [1]. Don't know if that's the latest or the demo version. Their demo vids are a good watch. [0] https://makepad.nl https://makepad.nl [1] https://makepad.dev https://makepad.dev
dceddia 1y ago
I know it’s usually taken as a given around here that Electron is slow, and many of the big-name apps using it are cited as examples with good reason. From working on a Tauri app myself for a few years (video editor) I just think the blame is misattributed. These things are not inherently slow. Slower than native? Maybe, probably, at the level of milliseconds. Visibly laggy? No, that’s the badly-written UI code’s fault. (see also: the latest iterations of the macOS System Settings UI, where the search box lags like crazy) A webview can be extremely responsive. It won’t be if you treat it like a web page (where clicking buttons fires off HTTP requests) or if you let the JS framework code get out of hand, but those are not the fault of the wrapper. If you like building with HTML/CSS/JS then I’d recommend doing some perf experiments to see how far these tools can take you. Of course if you don’t want to use that stack then pick something else :) If you’re building photoshop, the main UI will probably be canvas anyway, where drawing is fully under your control, no matter which framework you go with. That stuff can be very fast or very not-fast depending on how the code is written.

nicoburns 1y ago

> this is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine It's certainly a newer and lesser-known engine. It's mostly been me working on it for the past year or so (with a couple of other occasional contributors). But I do have funding to work on it full time through DioxusLabs (who are building Dioxus Native - a Flutter / React Native competitor on top of it) and NLnet (who are a non-profit interested in the alternative web browser use case). We're trying to really push on the modular side of things to create a web engine that's flexible / hackable and can be moulded for a variety of use cases. We'd love more contributors, so if anyone is interested in getting involved then drop by our GitHub (https://github.com/DioxusLabs/blitz/ https://github.com/DioxusLabs/blitz/) or Discord (https://discord.gg/AnNPqT95pu https://discord.gg/AnNPqT95pu - #native channel)

goku12 1y ago
You have my admiration and support for this work! I guess it goes without saying how monumental and critical the work on alternative engines like servo and libweb are. We are genuinely tired of the current duopoly (I'm starting to lose hope with Firefox and gecko as well. They seem to have priorities different to our expectations.) But I guess we now have one more to look forward to, thanks to you and the rest of the team! Personally, I hope to pitch in as soon as I have some spare time available. Regards!
- nicoburns 1y ago
  > You have my admiration and support for this work! Thanks! > Personally, I hope to pitch in as soon as I have some spare time available. Amazing - maybe see you around :)
dingi 1y ago
Just skimmed through the Blitz source. Really interesting. I don’t have experience with UI rendering or Rust, but I couldn’t help wondering: if you leave out things like local storage and websockets, why include networking at all? Feels like a separate concern. Genuinely curious. Great project. Wishing you all the best!

wodenokoto 1y ago

Wasn’t rust and servo co-developed?

goku12 1y ago
Yes. That's what I meant, in case my framing is confusing.