I always say I'd prefer to stick to backend stuff at job interviews and to everyone else because I haven't ever come across any gui solution that I genuinely find intuitive and clean. It's always a huge mess.
The problem here is that humans are, both individually and as a group, illogical, fickle, complicated things. It’s the same reason that Unidoce is a complicated mess, but writ large: there’s a bunch of essential complexity that we have to deal with somehow.
We’ve gotten pretty good at describing the craziness that is human language, but don’t even have good ways to talk about human behavior around computers.
I often question that term "essential complexity".
As it stands if I want to create a program with a GUI that can reach the most people, I have to support Apple devices and Apple operating systems/interfaces, I have to support Google devices and Google operating systems/interfaces, I have to support Linux and it's clunky old X Windows. All of which is to the exclusion of whatever else is out there.
A lot of this is not "essential complexity" but complexity caused by corporate entities, striving to stake out territory and lock as many as possible into their systems.
Of course there are all kind of frameworks that offer to paper over those difference and allow one to create GUI applications that will work across all those platforms. But then you are tying yourself to some other corporate entity.
Then there is the browser, so far the best way to deliver a GUI application to all kind of platforms from a single code base we ever had.
Except, today you can choose from Google Chrome, Microsoft Edge Chrome, Opera Chrome and soon by the looks of it Firefox Chrome. Or Apple Safari.
Meh. Anyway I demand a GUI framework.
It should be small and simple, it should work straight into the frame buffer on Linux (no X Windows) or whatever embedded device's screen I have. Heck, it should work straight into the frame buffer on Windows and Mac, get that OS nonsense out of the way.
Can we rip the rendering engine out of Firefox and have it do that?
1 Like
And coincidentally I find Adam Perry sums up what I have tried to say, and even think about, in this RustConf 2019 presentation : "Towards an Open Ecosystem of Empowered UI Development" RustConf 2019 - Towards an Open Ecosystem of Empowered UI Development by Adam Perry - YouTube
I don't think you're going to get most people unified around that idea. I would want a UI that does not include "parse JS, parse HTML, parse CSS" in any part of the process. None of these tasks are essential. I'd love to render into a frame buffer. (Game development!) Some people require access to native UI widgets, and they won't use knockoff brand tools. And why shouldn't they be able to, it's just a library. And other people want to write portable declarative code that works on any platform, even if it's somewhat inefficient. And of those, there are some who would prefer to write JS/HTML/CSS, etc. I think it would be really cool to have a UI which runs entirely on the stack. But that contradicts arbitrary nesting of widgets and supporting some dynamic behaviors. Which behaviors should be dynamic, and which should be fixed? There simply is not one solution which will suit most people's requirements.
1 Like
It's not just GUIs. Everything is fractured. Except maybe the ASCII table, or Unicode.
But then average people don't want to use the command line to do all their work. So we need GUIs.
I wish I could use Rust. I really like it. I had a honeymoon period for two or three weeks. But lack of an appropriate GUI stops me. I wish the makers of languages would take GUIs more seriously. I write desktop applications so the GUI is necessary for me. I think Microsoft got C# right when they provided a good GUI framework right off. What I really want is:
- a language to replace C/C++ with similar performance.
- RAII. That is, deterministic destruction. So no garbage collector.
- Cross-platform GUI framework in the native language. No bindings please.
I watched the D language for a long time and I like the language a lot. But they also don't think or talk about GUI much. (And of course it uses a garbage collector in the default case.) I guess all the people who like these languages are server/web programmers. A problem is that these languages expect independent volunteer developers to handle the GUI libraries which they try to do. But after a while these developers get bored with them and abandon them. So you have lots of dead end GUIs.
So for now I stick with C++ and JUCE which is my GUI of choice. But something like wxWindows or Qt is OK too. Anyway, I never wanted to use Rust for its memory safety---I've never had memory problems with C++ since unique_ptr.
Edit: BTW, can any of these Rust GUIs even do a dialog box?? I just want a dialog box.
We have a PR in flight for it. Reading the review thread might be instructive, why a problem that may seem trivial to you as a user has subtleties to it.
I keep writing more and then deleting. Participating in threads like this is not much fun for me. But be assured, work to make the situation better is happening.
5 Likes
Sorry about the tl;dr. It's been a long day, and this thread has been neat.
It should be small and simple, it should work straight into the frame buffer on Linux (no X Windows) or whatever embedded device's screen I have. Heck, it should work straight into the frame buffer on Windows and Mac, get that OS nonsense out of the way.
I'd really like to see that too. This would be a great thing to have in the Raspberry Pi space. It could be a nice alternative to Raspbian's kiosk mode which essentially runs a headless version of Chromium, IIRC? Although kiosk mode doesn't use a display server/compositor, the UI still depends on an HTML/CSS/JS browser engine and all of the bloat that comes with that.
As for there never being a great GUI framework: I'm convinced that we'll never have a perfect solution, but we can still get a whole lot closer. I also feel similarly about game engines and programming language paradigms. There are tons of engines out there, and lately, ECS is all-the-rage, but also, I really like ECS lol.
Language paradigms have this same problem: OOP was all the rage for the last couple of decades, and how there's been this less and less subtle shift towards FP. Personally, I really like FP, and ironically, realized pattern matching was missing from my life a couple years before I discovered the concept of pattern matching lol. It's just that there are people who think OOP is the way to go, and other who thing FP is the only answer. Personally, I think they're both tools that have their uses.
@raphlinus UI stuff is fun. The more this thread gets fleshed out, the more aware I'm becoming of other UI frameworks. For some reason, I just had this perception that Rust-UI hasn't matured just yet, but it looks like it's very possible to build GUI apps completely in Rust. Now, if all of the dependencies are built in Rust/idiomatic is probably another question, but it seems like this is coming along. I'd be surprised if we didn't have a couple full-featured "name-brand" UI frameworks for Rust in a couple of years.
A friend told me about Bevy a couple weeks ago. It looks pretty cool, but it's primarily an ECS-based game engine, right? I've only ever thought of ECS as more of a game-design paradigm, but it probably translates to UI pretty well, right? I mean, Flux/Redux is a popular form of application state management is kind of like ECS: separating data from behaviors. Redux has a store, ECS has a world. Systems are reducers. Actions are Components. Systems are basically action creators? Am I onto something? #tinfoilhattime
I agree about scoping out others' work. I spent so much time trying to build the "ultimate game engine that does everything and is the most performant" as a kid. Thing is, I had never used another game engine before... Turns out I was a poser, and learned everything the hard way. Did that for years, but that was only my first 10 years learning how to write code... The next 8 were quite a revelation when I got into Unity development.
I haven't checked out too many Rust-centric UI projects yet, but I've worked with various GUI frameworks over the years since the early 2000s: C WINAPI, WPF in C#, VB.NET (don't ask), worked with UIKit for iOS, Qt in C++, and worked with all major web food groups: React, AngularJS, Angular 2+, and VueJS. Ironically, the one framework I've worked the most with BY FAR is LitElement (and I prefer it over React, ironically). I even built an entire open source ecosystem around Lit too.
I didn't realize SwiftUI was finally a thing, but I wondered if Apple was going to develop something that fit the Swift language better. UIKit was neat for its time, but it didn't quite match up to what Swift was going for as UIKit was built during the OBJ-C era of Apple, so Swift needed some compatibility syntax to interop with OBJ-C bindings IIRC.
I was not particularly suggesting keeping the insanity of the HTML/CSS/JS chaos. Although I wonder how much "bloat" they actually are. As it happens Javascript is my second favorite language ever, it's amazingly sophisticated and flexible. Rust and JS are pretty much the only languages I use now a days.
But it seems to me, speaking mostly out of ignorance, that buried in a web browser, under all that HTML/CSS garbage is millions of lines of graphical rendering code that works pretty well. It is stuffed to the gunnels with useful GUI features from text rendering to accelerated 3D rendering. Not only that I'm told that a big chunk of that is now written in Rust in Firefox.
So, I wonder, why is nobody ripping that out of Firefox and making it a graphical library that can be used with any other program one writes, much the same as we use Qt or GTk?
Of course as it stands it requires use of the DOM API and hence Javascript, but I imagine being able to drive the DOM from web assembly directly at some point, thus making a language neutral GUI library.
How cool would that be?
1 Like
To me it's not about which language is good but what tool is fit for purpose. Having a browser engine as a dependency of my app can be wasteful. The OS already has a window manager, can render all the widgets, and the CPU can execute my code so in theory I shouldn't need a completely separate runtime and a renderer on top of that. The advantage of e.g. Electron apps is that they're multiplatform but it comes as a cost since the platform abstraction is the browser engine, i.e. something on top of an operating system and window manager. And if every Electron app comes with its own runtime, it all adds up very quickly.
I like the relative simplicity of UI frameworks built in JS/TS but to me a better approach would be to do all the heavy-lifting at build time and produce something efficient and lightweight. Memory, CPU, battery are resources I like to save. Svelte is the right way to go, although it still has a (for me) heavy runtime dependency. I'm looking forward to see more frameworks behaving like compilers.
In my world, I don't care how heavy is the build-time dependency, but I do care how heavy is the runtime dependency.
1 Like
Quite so. But as this is a Rust forum one speculate about a GUI system that is easy to use from Rust. Which in turns leads to: if there were such a Rust GUI system then GUIs would become another purpose for which Rust as a good fit.
In my conception of leveraging all the GUI rendering code in a browser engine, it need not be wasteful. At least in principle. Or at least not much more than using the shared libraries of Qt, GTk xlib, and the like.
I propose an "Electron like" thing need not come with all the junk that is in Electron. And as shared libs it need not be duplicated in every app. Just take the renderer, throw out everything else.We don't need node.js in there. Drive it all from a WASM API. Bingo we have a cross-platform, language neutral GUI rendering engine.
Does it have a heavy run time dependency? I took a look at Svelte after first hearing of it here. The Svelte "Hello world" example bundles down to 3K bytes. When does the heavy run time kick in?
Or do you mean the browser it runs in? Well that is huge, but everyone has one anyway so might as well make use of it.
Stylo is nowadays used to compute css styles. Integration of webrender (used for final compositing of the painted elements, The whole web at maximum FPS: How WebRender gets rid of jank - Mozilla Hacks - the Web developer blog) is being worked on. It is currently available behind the gfx.webrender.enabled feature flag.
If you wanted to have platform independent app then yes, although it'd still require the OS to compile WASM to native code. I could just as well do it at build time and provide native code binaries, no need for WASM.
Yes, I mean desktop apps in e.g. Electron. They don't run in your browser, they don't need your browser. They run inside their own copy of a bundled browser engine. Each app has their own copy. I know it's possible to share them but that's not the reality.
I certainly don't want platform dependent applications. I'm not in the business of supporting MS or Apple or Google or whoever. On the other hand I don't want to be limited to Linux users.
Well of course it will need an OS to compile it. Like everything I write unless it uses JS.
WASM is not essential to my suggestion. But it could be a neat way to create code in whatever language and you like an deploy it to all possible platforms.
Yes, I know.
It's kind of crazy Electron apps don't share a common browser engine and whatever run time. It should all come as an apt package like Qt, Gtk, xlib do. Still, never mind reality, we are dreaming of possibilities here.
I've just come across DearPyGui
If python is still working on GUIs is no wonder rust is 
It also made me wonder about using ffi into a more dynamic language such as python to attach a GUI to a rust core. In a similar vein there are a number of awesome scripting languages built in rust that are callable/embeddable in rust 
@happybeing @drmason13 I checked out Svelte, and its concept seems really interesting. Sounds like Svelte pre-compiles every permutation of a components syntax instead of readjusting it on-the-fly, so it can avoid most DOM reflow and repaint processes, right? If so, then can it handle declarative loops, or does that still have to be declarative if the loop isn't determinant? Either way, that seems neat. A Rust component framework should be able to perform something similar to that via code-gen right? Each permutation of a component could in theory be its own type in Rust, that's generated via a macro, right?
@ZiCog I'm with you there: JS is honestly my favorite language right now. I really enjoy Rust a lot, but it can encourage some aggressive namespacing at times which is a turn-off when I'm 3 namespaces deep. I tend to run into this issue with some of my crates from time to time, so this is probably a "me" thing, and so there's probably a skill I need to build up. Maybe deep namespacing is just a sign that it's time to break the crate up into smaller ones...
So, I wonder, why is nobody ripping that out of Firefox and making it a graphical library that can be used with any other program one writes, much the same as we use Qt or GTk?
Right? I did find it ironic that although Rust is still working on the GUI side of things, the language is developed by a company who's primary product is a GUI app lol. That said, it did start off as a fun side project, and it was probably even used as a more domain-specific language for a while before opening it up to the world.
Svelte is the right way to go, although it still has a (for me) heavy runtime dependency. I'm looking forward to see more frameworks behaving like compilers.
In my world, I don't care how heavy is the build-time dependency, but I do care how heavy is the runtime dependency.
Sounds like something that a language like Rust has the potential to deliver. I do like the idea of pre-compiling things.
1 Like
I can't answer the questions about Svelte other than that you are correct about it compiling reactivity. This makes the bundles tiny, and the UI responsive and performant. I don't see any reason why this couldn't be done using Rust, but I'm not clever enough to 'know'.
Svelte has two stand out features for me: 1) by compiling the reactivity it is compact and performant (Rich Harris, Svelte creator used to spend time demonstrating this by showing side-by-side comparisons), and 2) The way you build things in Svelte is very intuitive, assists both quick try outs/learning, and somewhat like Rust is very easy to grow and structure as and when it suits you or your project. This makes it an easy and fun framework to learn and use. I never found that with a UI framework before. There are a few weirdnesses, but more "ah this is cool"s, but anyone who remembers coming to Rust will be well used to weirdnesses 
.
I thought my original suggestion might be off-the-wall wishful thinking, but I'm starting to believe it is possible! Though beyond me :-). I remember Rich mentioning a while back he has a longer term hope for using Svelte components to build UI interactively, but I've not heard anything about using the approach with other languages (except perhaps wasm, but not sure about that).
If you want more informed answers, the Svelte Discord has a lot of helpful and knowledgeable folks, and if needed Rich is quite responsive on Twitter.
I'm not sure if this is what you mean by declarative loops but it's one of many "ah that's cool" things:
<script>
let cats = [
{ id: 'J---aiyznGQ', name: 'Keyboard Cat' },
{ id: 'z_AbfPXTKms', name: 'Maru' },
{ id: 'OUtn3pvWmpg', name: 'Henri The Existential Cat' }
];
</script>
<h1>The Famous Cats of YouTube</h1>
<ul>
{#each cats as { id, name }, i}
<li><a target="_blank" href="https://www.youtube.com/watch?v={id}">
{i + 1}: {name}
</a></li>
{/each}
</ul>
FYI, JUCE was initially released 19 years after C++ did. Just wait for 14 years and you'll have your JUCE for Rust.
On a more serious note, GUI development is hard and Rust was neither created by Google, Apple, Microsoft nor any other gigantic tech company. Some things simply take more time, if you cannot put near infinite resources into a project.
2 Likes
Everybody would love this in Rust! Good cross-platform GUI frameworks are hard though; tons of little details and corner cases and quirks to get right. The few existing frameworks that meet your bar (Qt, Swing, ...) are from large development teams working over many years. It's almost a given you need significant commercial intent behind it. I'd love to be proven wrong but I'd be surprised to see the hobbyist/open source community deliver it.
3 Likes