In general, we should be more willing to write code that's slightly less performant or elegant if it means that it's also less complex.
This, a thousand times this.
I love Rust, but the language features make it really tempting to overcomplicate your APIs by going for maximum performance. Yet judging by the popularity of React/Electron, GUIs don't need to be maximally performant: many users are willing to accept the overhead of a (relatively fast) single-threaded GC language. So long as the API is simple and compile times are fast, people will use it.
I'm partially joking and also out of my depth here, but I'm wondering if the ideal Rust GUI library is actually something like Rust wrapper→Lua framework→C bindings for your platform's GUI.
I'm partially joking and also out of my depth here, but I'm wondering if the ideal Rust GUI library is actually something like Rust wrapper→Lua framework→C bindings for your platform's GUI.
That is more or less what Qt and Slint do. Qt provides QML/QtQuick and Slint has a similar approach. They both provide an HTML inspired markup + JavaScript to glue events to C++/Rust code. Works pretty well in my limited experience.
Yet judging by the popularity of React/Electron, GUIs don't need to be maximally performant: many users are willing to accept the overhead of a (relatively fast) single-threaded GC language.
The primary issue with electron+whatever bloated js framework isn't really speed, it's the memory consumption. With the current RAM prices, seeing something like Slack or Discord eat up a whole gigabyte feels really bad.
I've made concerted attempts at using xilem, and even masonry underneath it a few times and it's been pretty brutal. So I agree on pretty well the points here.
The problem is there are some really good bits to xilem, but they're hindered badly by the experience of trying to develop something even moderately complex in it. You have to be really dedicated to get something out of it that matches what you originally envisioned without a lot of compromises along the way.
As I've played with more and more different gui frameworks, I really like the QT slots and signals mechanism and I wish there was sort of an evolution of that we could target and bring into xilem alongside an easier path to declaring a UI. I harp on the web all the time, but it's really easy to cobble together a UI with some HTML. Slint took a similar route. Separating the concern of declaring the views and UIs from the code a bit makes things feel clearer and might make it feel easier to get something up and working faster.
This has been my own experience when trying to build things bottom up rather than building things driven by concrete use cases. In the past, I have noodled away at multiple game engines without a clear idea of what the game I'm trying to make is and invariably ended up with a complicated, sprawling code base that is difficult to work with and nowhere near an actual game. On the other hand when working on an actual AAA game we had constant direct feedback of what was missing, what needed to change or what was causing slowdown. The resulting game engine was lean, surprisingly reusable and is AFAIK still in use today.
I think starting or refocusing on the actual goal ("We are building THIS application with THESE needs") would be very clarifying as to what is actually helpful and necessary and what can be trimmed.
I am thankful Xilem is still getting attention. The GUI scene in Rust is still not great. I've been eyeing Xilems development ever since Raph made his blogpost introducing it four years ago. (Xilem: an architecture for UI in Rust) I also liked his post on Advice for the next dozen Rust GUIs.
icefox | 22 hours ago
Helpfully, Xilem is "an experimental Rust architecture for reactive UI".
bitshift | 15 hours ago
This, a thousand times this.
I love Rust, but the language features make it really tempting to overcomplicate your APIs by going for maximum performance. Yet judging by the popularity of React/Electron, GUIs don't need to be maximally performant: many users are willing to accept the overhead of a (relatively fast) single-threaded GC language. So long as the API is simple and compile times are fast, people will use it.
I'm partially joking and also out of my depth here, but I'm wondering if the ideal Rust GUI library is actually something like Rust wrapper→Lua framework→C bindings for your platform's GUI.
[OP] PuercoPop | 12 hours ago
That is more or less what Qt and Slint do. Qt provides QML/QtQuick and Slint has a similar approach. They both provide an HTML inspired markup + JavaScript to glue events to C++/Rust code. Works pretty well in my limited experience.
hjvt | 8 hours ago
The primary issue with electron+whatever bloated js framework isn't really speed, it's the memory consumption. With the current RAM prices, seeing something like Slack or Discord eat up a whole gigabyte feels really bad.
Levitating | 7 hours ago
GTK4 apps are not much better, sadly.
objectif_lune | 22 hours ago
I've made concerted attempts at using xilem, and even masonry underneath it a few times and it's been pretty brutal. So I agree on pretty well the points here.
The problem is there are some really good bits to xilem, but they're hindered badly by the experience of trying to develop something even moderately complex in it. You have to be really dedicated to get something out of it that matches what you originally envisioned without a lot of compromises along the way.
As I've played with more and more different gui frameworks, I really like the QT slots and signals mechanism and I wish there was sort of an evolution of that we could target and bring into xilem alongside an easier path to declaring a UI. I harp on the web all the time, but it's really easy to cobble together a UI with some HTML. Slint took a similar route. Separating the concern of declaring the views and UIs from the code a bit makes things feel clearer and might make it feel easier to get something up and working faster.
krig | 10 hours ago
This has been my own experience when trying to build things bottom up rather than building things driven by concrete use cases. In the past, I have noodled away at multiple game engines without a clear idea of what the game I'm trying to make is and invariably ended up with a complicated, sprawling code base that is difficult to work with and nowhere near an actual game. On the other hand when working on an actual AAA game we had constant direct feedback of what was missing, what needed to change or what was causing slowdown. The resulting game engine was lean, surprisingly reusable and is AFAIK still in use today.
I think starting or refocusing on the actual goal ("We are building THIS application with THESE needs") would be very clarifying as to what is actually helpful and necessary and what can be trimmed.
Levitating | 7 hours ago
I am thankful Xilem is still getting attention. The GUI scene in Rust is still not great. I've been eyeing Xilems development ever since Raph made his blogpost introducing it four years ago. (Xilem: an architecture for UI in Rust) I also liked his post on Advice for the next dozen Rust GUIs.