I've been building a profiler UI in egui recently, and have been pretty happy with it. I didn't try out all of the options in this article (there are rather a lot of them), but I did try several, and out of the ones I tried, egui was by far the highest performance. Since my goal is to shove as many rectangles onto the screen as possible, this was the killer feature for me, but it was also nice that it did most of the other GUI stuff I needed.
Cool demo, but by the looks of things the whole site is rendered into a canvas element. As a result, the browser's dev tools are useless, it won't work with screen readers, and you can't copy+paste text. And any text rendering and input elements will be non-native. (So, no nice iphone controls. No native / system configurable keyboard shortcuts. And so on.)
I sincerely hope the web as a whole doesn't move in this direction. The inspectibility of the DOM is one of the web's greatest strengths. Lets not throw that away.
What makes egui so fast? I thought immediate mode GUIs have a convenient API at the expense of unnecessary redraws and lower performance.
Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.
I understand that this is a demo, but actually drawing all 8,000 nodes instead of just 3 screenfuls (6 nodes on my screen) and updating them dynamically when scrolling isn't what I would call 'performant', but needless waste of resources.
Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.
wow, i am genuinely impressed! super snappy. I wonder whether it could be used to tackle a real pain point of mine. I work a lot with data, visualisations with jupiter notebooks. There are essentially two approaches: matplotlib, which outputs pngs/svgs. The notebooks stay fast but they are not interactive. The other is approaches like plotly, js-based, interactive, very useful but it gets slow really fast. I can not handle a lot of data. It can not handle a lot of plots. A simple, interactive plotting library with a focus on speed would be immensely useful! With python bindings. Could be a fun weekend project. I don't know any rust though, anybody up to collaborate? :P
I bet the canvas approach would not slow-down the notebook.
I hope it's OK to add a shameless plug for my Rust WASM framework, Silkenweb [0]. It's similar to Leptos and Sycamore in that it's signals based, but I've put a lot of effort into making it ergonomic without resorting to a macro DSL. It supports all the usual things like SSR and hydration, along with a few nice extras like scoped CSS.
I love how simple your cargo toml is. A big turnoff of leptos for me was the incredibly messy cargo toml of the examples. I could barely touch it without bricking the project.
While I'm usually a no-macros kinda guy, but (I believe) leptos and dioxus provide tooling to hot-reload markup-only changes without (incremental) recompilation. Do you think that would be possible withour macros?
Author here! I've added it to my TODO list and will update the article at some point coming week or two. Love how the library looks like - thank you for the link!
> GUI in Rust progresses with unprecedented speed – 3 months in Rust GUI-land is like 3 years in the mortal world.
areweguiyet.rs was started almost exactly 5 years ago. That means it's been about 60 mortal years and we still don't have a definitive solution to GUIs.
Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page).
Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.
Since people will bring up AccessKit, assuming it to be a potential panacea (… despite the obvious performance cost of doing absolutely everything twice):
The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-purpose web content and apps, in ways that things like AccessKit cannot fix. I’ve written about this a few times; https://news.ycombinator.com/item?id=33861831 is probably the best thread. The two items I like to focus on are links and scrolling, both of which are unavoidably broken.
Desktop solutions don't use wasm/canvas for their primary use. Although you can wasm to compile it for web demo, they are primarily meant to be used as native apps outside of a browser.
I think it's interesting that we take it for granted that accessibility is primarily the responsibility of GUI toolkit developers. I would think that maybe some amount of blame would fall on OS vendors, who have billions of dollars flowing through their organizations, rather than some random open source projects.
If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way.
[0]: I am aware of AccessKit. Where's the OS backing?
This may not be the message of the article but as a side-rant:
I really don't understand the use-case for a Rust-based GUI.
Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.
I understand that not every UI needs to be a cross-platform blah blah blah written in TypeJavaReactScriptJS, or a pixel-painted canvas written in Flutter. I also understand there's a use-case for one-off UIs that may not target a browser.
Let's compare it to something like Golang. Fast compile times, similar libraries, garbage collection -- it seems like something more suited for UIs where there are usually a lot more iterations. Worse performance for sure, but Rust also seems more-than-overkill in that regard for the UI use-case.
From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them.
Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll probably hate golang.
We also find that once you get used to the borrow checker, we mostly don't miss garbage collection. And garbage collection isn't a panacea either, as almost any large project still ends up with memory leaks caused by stray references.
So, basically, we like Rust and think its a well designed language. It is quite frankly better, as a language, than any of the alternatives that we could be writing in. As such, it'd be nice if we could develop GUI applications in it.
> I really don't understand the use-case for a Rust-based GUI.
For people already writing things (libraries, cli's etc) in Rust who want to add a GUI while staying with the language. No great mystery.
As for a business case, aside from individual developer taste/preference, it's hard to see that there is one outside of niches. System76 found a case for it with their DE. I think there might be a strong case for lightweight Rust GUI frameworks like egui for embedded device displays.
But for mainstream web / desktop / mobile apps? I can't at the moment see what the point would be.
Things are a bit different in certain graphics app domains, where you need to create complex tools for professionals (think of image editing, 3D modeling, video processing, CAD, game engines, etc.) The users demand all kinds of functionality that requires squeezing the CPU and GPU to the fullest extent. And you have to do this while designing a complex UI with numerous complex controls, and it also needs to be butter-smooth. (Also note that the majority of the low-level APIs/drivers you need to use are in C/C++!) In that case, using languages like Go/Java/Javascript creates more problems than it solves (even if you only write the core in C++/Rust and use bindings.)
> Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.
What about a vector or image editor, a 3D DCC etc?
These are prime example for desktop apps where existing solutions are 100% written in C++.
That's stuff where Rust would be a better alternative if you started work on an app like this today.
In VFX there is a whole initiative by the ASWF to wrap the stack in Rust for starters and possibly have new additions written in that language instead of C++ in the future.
And compiling to WASM and being able to run in a browser (even if only as a single canvas element with all applying limitations) is a great plus.
Yeah it seems to be a pretty niche use case. The learning curve for Rust is simply too high (my GOD the syntax). You can just get much more done, in less time with a web framework.
I looked into Rust for writing games (including the UI frameworks), but found that the power it provides isn't really worth all the mental overhead. Most games don't really need that much power, particularly if you are using non-realistic graphics. In the event that you do actually need extra optimization, most engines let you hook down into C++ for raw performance.
I am glad that there are people looking at GUI from the perspective of Rust. Many Rust idioms and patterns, like ownership and immutability, are very promising for GUI development.
However, this article also confirms an issue I have observed with the Rust ecosystem, which is fragmentation. It would have made me much more excited to see convergence behind one project than 15 different ones. I think Rust enthusiasts, bless their hearts, are often so excited about the puzzle of the language representations, that the output often ends up being more of a POC than a well-maintained library for users. It seems more-than-usual amount of projects are abandoned when the intellectually stimulating honeymoon phase is over. As a prospective user, this is probably fine for small leaf-dependencies, but it’s a major show-stopper for something like GUI.
I’ve never expressed it like this before, but I think there’s a moderately serious issue when a language seduces you away from the domain problem and towards the language itself, even if that is subjectively enjoyable. (In other languages like perhaps Java or C++, the language quirks are at least so dreadful that only masochists are spending more time than necessary on it)
> an issue I have observed with the Rust ecosystem, which is fragmentation.
Absolutely. The fragmentation doesn't matter with all library types, because they don't all need the vast array of associated libraries, tools, common practices etc which mainstream GUI apps lean on.
Wide GUI framework/library adoption needs a head of steam (far more than it needs architectural elegance). Right now I don't foresee this happening with Rust. Not everything is foreseeable, of course.
I've been using Flutter with flutter_rust_bridge pretty successfully, seems like a few other people I've talked to are as well, would want to see it covered in this article as well.
I doubt Rust is going to become used for (the GUI layer of) GUI apps far outside of Rust enthusiast circles. To build a widely attractive ecosystem it needs a dominant framework to which enough of the many widget and theming and distribution libraries and tools necessary for broad adoption attach. Rust's culture in this respect is far more Clojure (bolt together your own from a thousand options) than Elixir (just use Phoenix).
I have no doubt Rust will be used as part of many GUI apps via Tauri and others. 1Password shows how successful it can be as the real core of an app that has a separate web-tech GUI layer.
There's enough energy in the Rust ecosystem that I'm sure niche adoption will continue. But all-Rust apps beyond HN/Github-browsing/System76 circles? My guess is it's unlikely.
My guess is Rust is going to experience its first test in the next two years, where the general people will see what it's really good for, and what's it not, because it won't be the "new hot thing" anymore.
Only then we will know if it has chance of really becoming widely used as a general purpose PL.
Did anyone say that something was wrong with typescript? It’s my preferred language these days, in non-tech enterprise you’ll basically have to use it and since it’s good enough for everything, it’s easy to have small teams that can all work together in one language. This means the frontend developer gets to go on vacation (or call in sick) without bringing a laptop. It also means you can easily share in-house libraries and ask each other for ideas/troubleshooting more easily. And so on, there are obviously downsides as well but over all it’s a joy to work with.
That doesn’t mean I don’t want Rust “people” to work on frontend stuff for Rust. Typescript is good, I like using it, but I’d like to have options. If not for anything else, then for Typescript to take the best parts of Rust and use them.
I don’t personally think we’re going to see a massive shift away from a JavaScript world until someone like Microsoft starts driving the change. The amount of resources they pour into Typescript means it’s not likely to leave my world any time soon. But if it did, and something better came along then I’d be happy, not sad.
I love typescript, but, from my PoV, what I miss in typescript is:
- An actually sound type system: This is a big one. Can you figure out why this[0] is unsound?
- I regularly have to do `as ` assertions, and I know it's not because I'm bad at typescript because it's often the recommended solution from cream-of-the-crop tS libraries for certain issues.
- Traits
- new-types
- Algebraic data types: Option and Result. 'nuff said.
- Pattern matching: :cheff's kiss:
[0]
export function useSetter<T, K extends keyof T>(
state: T,
setState: (n: T) => void,
key: K
) {
return useCallback(
(val: T[K]) => setState({ ...state, [key]: val }),
[key, setState, state]
);
}
I understand the requirements of having a dedicated canvas and a decent UI running on it for things like games, CAD, 3D modeling and image manipulation apps. At the same time I don’t want my web bank using it. And unfortunately that’s usually what comes out from this.
Im a Flutter developer, and, though I love Dart, it's still only my second favorite language, so I can't wait for a viable "flutter alternative to emerge in the Rust ecosystem.
Give it enough time, and anything will happen. JS to Rust compiler with DOM bindings. Pure canvas Rust UI frameworks with even better accessibility than Web DOM. Whatever. People are so eager to claim X won’t be able to do that, etc.
The biggest problem is that there is no dominant solution. Right now having a rust-based app is a luxury when there are easier albeit 'dirtier' solutions. I don't have to build something in rust and I am dreadfully afraid that I'll spend hundreds of hours building something only for an altenrative to be the emergent solution forcing an expensive rewrite.
I wonder if WebGPU could help with app GUI. I tried to understand how does it work but it seems it's all about triangles, so it's not really clear if it has any benefit over plain Canvas for standard UI approaches.
Please don't use canvas or webgpu for GUI unless it's a game or other interactive experiment. Webgpu will drop compatibility with hardware and no accessibility, you would have to build everything up from ground again that web browsers already offer with DOM like flutter does by having "overlay DOM" on top of canvas to provide accessibility, and it's kinda janky. Now that's out of the way, sure you can do GUI with webgpu, see for example IMGUI or NanoGUI (NanoVG based).
I am betting on Vlang instead. Rust is too complicated for an average person - like me. It's basically the Haskell of system programming. V is basically Go made right.
[+] [-] eslaught|2 years ago|reply
WASM demo here if you want to see it (with dummy, and not particularly realistic, profiling data): https://elliottslaughter.github.io/legion-prof-viewer/
For comparison, the UI I'm replacing falls down with about 16 nodes worth of data. (The demo has 8192 "nodes" worth of fake data.)
[+] [-] josephg|2 years ago|reply
I sincerely hope the web as a whole doesn't move in this direction. The inspectibility of the DOM is one of the web's greatest strengths. Lets not throw that away.
[+] [-] osener|2 years ago|reply
Would it be faster than iced or Slint at rendering scrollable list with thousands of rows with images and text? For the sort of use case you’d use a “virtualized list” implementation for React for example.
[+] [-] ReleaseCandidat|2 years ago|reply
Btw: when clicking any 'task' to get to see the details, I see a repeating pattern of almost vertical stripes in some colors. I guess that's not what it should look like.
[+] [-] LeanderK|2 years ago|reply
I bet the canvas approach would not slow-down the notebook.
[+] [-] echelon|2 years ago|reply
https://www.egui.rs/#demo
Egui slaps and is clearly going places.
[+] [-] rkagerer|2 years ago|reply
I don't like how those textboxes get bigger when you click into them.
[+] [-] ljsb|2 years ago|reply
[0] https://github.com/silkenweb/silkenweb
[+] [-] 7znwjshsus|2 years ago|reply
[+] [-] davidatbu|2 years ago|reply
[+] [-] Firfi|2 years ago|reply
[+] [-] mcluck|2 years ago|reply
areweguiyet.rs was started almost exactly 5 years ago. That means it's been about 60 mortal years and we still don't have a definitive solution to GUIs.
[+] [-] CJefferson|2 years ago|reply
Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.
[+] [-] chrismorgan|2 years ago|reply
The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-purpose web content and apps, in ways that things like AccessKit cannot fix. I’ve written about this a few times; https://news.ycombinator.com/item?id=33861831 is probably the best thread. The two items I like to focus on are links and scrolling, both of which are unavoidably broken.
[+] [-] jenadine|2 years ago|reply
I know Slint and egui have accessibility support.
[+] [-] capableweb|2 years ago|reply
[+] [-] hnon|2 years ago|reply
If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way.
[0]: I am aware of AccessKit. Where's the OS backing?
[+] [-] eviks|2 years ago|reply
(but hopefully it'd be a temporary step back)
[+] [-] low_tech_punk|2 years ago|reply
[+] [-] TobyTheDog123|2 years ago|reply
I really don't understand the use-case for a Rust-based GUI.
Rust's syntax, manual memory management, and compile times makes it seem like it's really not meant for this kind of workload, but instead for things like compilers, embedded systems, that kind of thing.
I understand that not every UI needs to be a cross-platform blah blah blah written in TypeJavaReactScriptJS, or a pixel-painted canvas written in Flutter. I also understand there's a use-case for one-off UIs that may not target a browser.
Let's compare it to something like Golang. Fast compile times, similar libraries, garbage collection -- it seems like something more suited for UIs where there are usually a lot more iterations. Worse performance for sure, but Rust also seems more-than-overkill in that regard for the UI use-case.
[+] [-] winstonewert|2 years ago|reply
We also find that once you get used to the borrow checker, we mostly don't miss garbage collection. And garbage collection isn't a panacea either, as almost any large project still ends up with memory leaks caused by stray references.
So, basically, we like Rust and think its a well designed language. It is quite frankly better, as a language, than any of the alternatives that we could be writing in. As such, it'd be nice if we could develop GUI applications in it.
[+] [-] crispinb|2 years ago|reply
For people already writing things (libraries, cli's etc) in Rust who want to add a GUI while staying with the language. No great mystery.
As for a business case, aside from individual developer taste/preference, it's hard to see that there is one outside of niches. System76 found a case for it with their DE. I think there might be a strong case for lightweight Rust GUI frameworks like egui for embedded device displays.
But for mainstream web / desktop / mobile apps? I can't at the moment see what the point would be.
[+] [-] cyber_kinetist|2 years ago|reply
[+] [-] virtualritz|2 years ago|reply
What about a vector or image editor, a 3D DCC etc?
These are prime example for desktop apps where existing solutions are 100% written in C++.
That's stuff where Rust would be a better alternative if you started work on an app like this today.
In VFX there is a whole initiative by the ASWF to wrap the stack in Rust for starters and possibly have new additions written in that language instead of C++ in the future.
And compiling to WASM and being able to run in a browser (even if only as a single canvas element with all applying limitations) is a great plus.
[+] [-] 0000000000100|2 years ago|reply
I looked into Rust for writing games (including the UI frameworks), but found that the power it provides isn't really worth all the mental overhead. Most games don't really need that much power, particularly if you are using non-realistic graphics. In the event that you do actually need extra optimization, most engines let you hook down into C++ for raw performance.
[+] [-] klabb3|2 years ago|reply
However, this article also confirms an issue I have observed with the Rust ecosystem, which is fragmentation. It would have made me much more excited to see convergence behind one project than 15 different ones. I think Rust enthusiasts, bless their hearts, are often so excited about the puzzle of the language representations, that the output often ends up being more of a POC than a well-maintained library for users. It seems more-than-usual amount of projects are abandoned when the intellectually stimulating honeymoon phase is over. As a prospective user, this is probably fine for small leaf-dependencies, but it’s a major show-stopper for something like GUI.
I’ve never expressed it like this before, but I think there’s a moderately serious issue when a language seduces you away from the domain problem and towards the language itself, even if that is subjectively enjoyable. (In other languages like perhaps Java or C++, the language quirks are at least so dreadful that only masochists are spending more time than necessary on it)
[+] [-] crispinb|2 years ago|reply
Absolutely. The fragmentation doesn't matter with all library types, because they don't all need the vast array of associated libraries, tools, common practices etc which mainstream GUI apps lean on.
Wide GUI framework/library adoption needs a head of steam (far more than it needs architectural elegance). Right now I don't foresee this happening with Rust. Not everything is foreseeable, of course.
[+] [-] FL33TW00D|2 years ago|reply
[+] [-] satvikpendem|2 years ago|reply
[+] [-] crispinb|2 years ago|reply
I have no doubt Rust will be used as part of many GUI apps via Tauri and others. 1Password shows how successful it can be as the real core of an app that has a separate web-tech GUI layer.
There's enough energy in the Rust ecosystem that I'm sure niche adoption will continue. But all-Rust apps beyond HN/Github-browsing/System76 circles? My guess is it's unlikely.
[+] [-] bsaul|2 years ago|reply
Only then we will know if it has chance of really becoming widely used as a general purpose PL.
[+] [-] Liberonostrud|2 years ago|reply
[+] [-] devjab|2 years ago|reply
That doesn’t mean I don’t want Rust “people” to work on frontend stuff for Rust. Typescript is good, I like using it, but I’d like to have options. If not for anything else, then for Typescript to take the best parts of Rust and use them.
I don’t personally think we’re going to see a massive shift away from a JavaScript world until someone like Microsoft starts driving the change. The amount of resources they pour into Typescript means it’s not likely to leave my world any time soon. But if it did, and something better came along then I’d be happy, not sad.
[+] [-] crispinb|2 years ago|reply
Larger bundle sizes - yes that's still true.
And not all GUIs are web GUIs, so WASM isn't the whole story.
[+] [-] andyp-kw|2 years ago|reply
[+] [-] davidatbu|2 years ago|reply
I love typescript, but, from my PoV, what I miss in typescript is:
- An actually sound type system: This is a big one. Can you figure out why this[0] is unsound?
- I regularly have to do `as ` assertions, and I know it's not because I'm bad at typescript because it's often the recommended solution from cream-of-the-crop tS libraries for certain issues.
- Traits
- new-types
- Algebraic data types: Option and Result. 'nuff said.
- Pattern matching: :cheff's kiss:
[0]
[+] [-] _trackno5|2 years ago|reply
If you're talking about Wasm with Emscripten, yes there's a cost of loading the runtime because Emscripten comes bundled with a lot of stuff.
I'm skeptical that just wasm itself was slower or heavier.
[+] [-] fmeyer|2 years ago|reply
I understand the requirements of having a dedicated canvas and a decent UI running on it for things like games, CAD, 3D modeling and image manipulation apps. At the same time I don’t want my web bank using it. And unfortunately that’s usually what comes out from this.
[+] [-] LatticeAnimal|2 years ago|reply
[+] [-] serial_dev|2 years ago|reply
[+] [-] Aerbil313|2 years ago|reply
[+] [-] preommr|2 years ago|reply
[+] [-] eviks|2 years ago|reply
For example, maybe you feel that VDOM is pure overhead and want to hide all frameworks that use it.
It's a bit disorienting to read many rather shallow lists with all the various frameworks without a proper convenient way to compare them
[+] [-] vbezhenar|2 years ago|reply
[+] [-] Cloudef|2 years ago|reply
[+] [-] fulafel|2 years ago|reply
[+] [-] low_tech_punk|2 years ago|reply
[+] [-] doodlesdev|2 years ago|reply
[+] [-] Liberonostrud|2 years ago|reply
[+] [-] plaguepilled|2 years ago|reply