Show HN: Graphite, a Blender-inspired 2D procedural design Rust app

What UI crate are you using for the GUI?

Right now, it's a custom HTML/CSS/TypeScript component system using Svelte built to minimize bloat. But since Graphite is a data-driven graphics app and render engine, we are planning to gradually rewrite our UI components as Graphite documents— allowing us to design the editor's UI within its own editor UI. Once that happens, we can probably drop the web dependencies— although we've taken pains to ensure our current web dependencies are very lightweight and performant. All the slow parts of Graphite are due to backend engineering shortcuts we've taken to enable forward progress, and those are stopgaps that are actively being worked on to be rebuilt into proper, high-performance systems.

Have you considered using Iced? It can be hard to figure out at first but it's blazing fast, cross-platform and can compile to WASM. It's also _beautifully_ designed.

Importantly, it's both "just Rust" and "very Rust". You can stay on the yellow brick road and kinda just get the app out there with incredible multi-threaded CPU + GPU rendering performance from the outset... or dig deeper and go into advanced stuff. Per the docs, it "leverages Rust to its full extent: ownership, borrowing, lifetimes, futures, streams, first-class functions"... it's just up to you how much of that you want to use

The documentation is admittedly WIP but if you need help, the Discord server is very helpful. I'm there virtually 24/7 and happy to answer any questions

The repo is at https://github.com/iced-rs/iced -- check out the readme for two complex apps recently built. It's fully themeable so you can make apps look exactly as you want them to (which is a downside for those looking for more native widgets)

It was a top contender when I was picking a GUI solution but it didn't meet the cut. Remember that this was 3.5 years ago. The decision to go with HTML/CSS was undoubtedly the right one and it'll continue to treat us well for the foreseeable future. But we are beginning to rewrite certain areas, like the node graph, in our own render stack because this streamlines the code best. And other widgets like histograms, color scopes, etc. will continue to be built with our own renderer. And then at some point, it will start making sense to begin gradually replacing other parts of our UI with the regular widgets like buttons and checkboxes with that system. Doing so will help us simplify things and make them more user-customizable, so plugin authors can affect the UI, etc.

I sincerely doubt you will be able to match the performance of native widgets with immediate-mode render libraries.

It's your app, so obviously do whatever you want, but I agree with the sibling comment that an immediate mode GUI wastes valuable CPU cycles redrawing the frame repeatedly and will invariably hurt performance

Again, since iced is "just rust", you can write whatever widgets you need, although it comes with a long list of built-in widgets (and there are many more built by the community). You can compose views with a bunch of these widgets to get to the UI you want.

There's also nothing stopping you from creating a way for users to write widgets for your iced application. The sky is the limit.

And I'm singling out iced because I'm a fan, but this should be true for pretty much all robust GUI toolkits out there.

Isn’t iced immediate mode?

No, it's a bit of a mix. Retained until some update is processed by the runtime which causes the widget tree to be rebuilt, in which case it gets diff'd and stale widgets get replaced. Some widgets always redraw though, like Canvas, but they expose caching functionality

I'm no authority here but that's the gist of my understanding